With Tunes, one must be able, with reasonable ease, to create high-quality text-based documents.
Abolish the modern-day concept of a word processor. Programs such as MS Word have 100x as many features as a simple text program ought to, and, as a result, are very big, slow and non-intuitive. Tunes must be different.
Word Processing apparently falls under the greater category of "Professional 2D Document Publishing", something that also includes graphics and DTP. The future of such publishing seems to be heading towards, and should head towards, much more modular, flexible and open architectures, architectures, perhaps such as OpenDoc and OLE, where small, managable-sized components are stacked together to build much more friendly, usable working environments.
There should exist seperate text, graphics, spell-check, thesaurus, (ad nauseum) modules, each of which is loosely integrated with the rest, and each of which is easy to replace, should a better or preferable version come along.
The Tunes Interface subproject principles dictate that all these modules and systems they compose into should be usable in whatever terminals are possible.
A set of structure-based editing tactics for this language could be made: this would constitute the "word-processor". However, since this framework would be embedded in the HLL, users could use meta-level operations to automate things that traditional word processors are not capable of.
Because every single sub-object of their document will be a first-class Tunes object, and any first-class Tunes object can be embedded in their document through adaptation (wrapping or meta-programming), any Tunes operation can be done on it.
Hence, I could study some problems, acquire data in a specific format with specific semantic operators; treat this data in many ways; define functions and concepts to manipulate a large class of data, define styles to display the data in various ways, and automatically generate from my same Tunes workplace lots of information extracts as 2D documents:
But because arbitrary Tunes objects, not 2D graphical data, constitute the common Tunes language, publishing in that format, which is good for paper documents, would not be the limit. I could publish a read-only (i.e. copy-on-write) version of most my very workplace (stripped from private/development parts).
The reader is also capable of some independence: instead of having to contend with the precomputed output of prebuilt static tactics, the reader could interactively propose his own personalized tactic. So, he would discover my reports, choose which part to expand and which to keep summarized according to his own taste and background. He could then ask for exercise hints precisely for the exercises he tried and didn't find, while being able to interactively use the concepts I defined with his computer in a semantically-preserving way; these concepts would be live objects with their own behavior playing out live. He could arbitrarily make queries on things in my document with his own familiar information extraction tools, instead of having to adapt to mine. He could also reliably write comments on the objects I published, and perhaps even publish them in turn, etc. This last part is an example of distributed annotation.
Because Tunes can manipulate side-effective structured objects instead of isolated linear bytestreams, it removes the problem of having to explicitly copy object representations and references, with all the associated desynchronization problems (about this latter problem of current systems, see Tunes Distributed Publishing).