The Tunes Interfaces Subproject

Word Processing Considerations


With Tunes, one must be able, with reasonable ease, to create high-quality text-based documents. Frankly, I'm tired of resorting to my 68020 Mac to create professional looking stuff using a most horrid MS Word while my Linux-based Pentium 90 sits on my desk, idle.

Tunes' WP Goals

Chris Ambles...

In Tunes, I think we should 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, is very big, slow and non-intuitive. Tunes must be different.

First off, I think Word Processing really falls under the greater category of "Professional 2D Document Publishing", something that also includes graphics and DTP. (Perhaps this page is misnamed, but I figured a 12 sylable name would be a bit obnoxious.) 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.

In Tunes, there should exist seperate text, graphics, spell-check, thesaurus, ... 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.

My personal preference is towards WYSIWYG interfaces, somewhat like (though much more OO than) today's DTP packages, or perhaps even ClarisWorks. However, how such interfaces could be readily created in text-only mode, some auditory-only mode, or through some other "strange" method of interaction, remains a mystery to me.

Fare replies

Yes yes yes, but all that should be done in a reflective way: the user should be able to define the meaning of his document, and independently refine the tactics by which (things known as style files in word processors and Currently, TeX is a great piece of reflective software for 2D typesetting. Only it requires ugly ASCII input, and is reflective in the same dirty way as all macro-expansion based systems, which prevents easy and/or clean manipulation by interactive and/or higher-level tools.

What I'd like to do is a better, cleaner, TeX. It would be reflective, but in a semantically clean way, rather than with uncontrollable macros that have to be written in low-level continuation-passing style for anything complex. You'd have all the power of the Tunes HLL, with a collection of predefined concepts and tactics corresponding to 2D typesetting.

Because this would be cleaner, a set of structure-based editing tactics for this language could be done, and guess what? it would be the very "word-processor"! By not creating meta-objects, or only very simple ones, and not using the language's capabilities, casual users end up with the very same as current word-processors.

but because every single sub-object of their document is a first-class Tunes object, and any first-class Tunes object can be embedded in their document, they can trivially achieve what is so difficult to classical systems; for a Tunes-embedded object is not just for display; 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, is the common Tunes language, instead of publishing only that, which is good for paper documents, I would publish a read-only version of most my very workplace (stripped from private/development parts); instead of having to content 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, and he would 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. He could arbitrarily make database-type queries on stuff 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.

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 against the WWW), etc.


Up to the Interfaces Subproject
Up to the Tunes Home Page
Page maintainer: Chris (chrisha@simba.lakeside.sea.wa.us)