Programs and Text

In current operating systems there are some executable files called programs that the user invokes explicitly. In a fully developed text-oriented operating system there are no more separate closed files at all. The functionality is tied together with the text structure and is exposed as some unit types. Whenever a type is instantiated, the user gets all transformation possibilities exposed by all related software packages that are available on the system. When installing software, new units are appended to the text repository and some of them can be tied with executable images such as parsers, presentation managers and transformations that will be invoked by the operating system whenever required.

For example, after installing a word processor the system knows about a unit type Prose. Each time the user instantiates it, for example:

= myNextProject {
	= Vision : Prose
}

she or he can open Vision in a separate window for word processing purposes, or print it, or export it into an electronic book format. The user can also add own functionality to the unit Prose, for example through a script that automates certain manipulation steps or through a complete program. If one has installed more than one package that can process units of some type, one can work on each instance with any of them.

The types are not big bags comparable to today's ”file extensions,“ they can be very fine grained. For example, although there is a Prose type, it contains subtypes such as Paragraph, List or Heading, each of which can be attached to third party software packages or the user's own developments. For example, after installing a spell checker software you can check all your natural language sentences in all articles that you write with a word processor, all lists that you write through a spreadsheet software, all your notes, electronic mail messages, etc. In a fully developed text-oriented operating system that would be valid in general without exception out of the box.

Note that this presupposes either a standard ontology of common types or a standard equivalence system to map types from different software publishers to each other, in order for software pieces from different publishers to cooperate well together. This is certainly difficult to achieve, much more difficult than today's private agreements between two publishers or the pure imposition by the big ones. But if we manage to do it, the systems will be incomparably better integrated than now.