Eliminating Conventional File Systems
Conventional operating systems and programming languages (including OO languages) usually support a variety of different structuring techniques, such as programs, library modules, files, etc. In Timor such structural units do not exist as separate entities but are all simply subsumed under the concept of types and their implementations (and thus have all the advantages of the information hiding principle).
- A "program" in the conventional sense can be regarded as an information hiding module with a single interface method and only temporary data structures. But why make that restriction? One could provide a program module which has several interface methods. A games compendium, for example, might have separate interface methods for different board games such as chess, draughts, fox and hounds, etc.
- A "library" can similarly be regarded as a module with multiple interface methods, and is thus structurally the same as a program.
- A "file" can also be viewed as a module which contains a major data structure with interface routines via which the data is accessed.
These ideas, especially the idea of treating files as information-hiding modules, will certainly seem strange to many. The reason is that even modern computer science accepts as a fact of life that operating systems, and therefore programming languages, reflect and reproduce the dichotomy that exists at the hardware level between file systems and virtual memory, i.e. the distinction between
- a very fast but expensive main memory (RAM) and
- somewhat slower mass memory devices (e.g. hard drives).
These two categories of memory devices exist, and will probably continue to exist into the foreseeable future, because main memory devices based on electronic circuitry are not only faster than mass memory but they are also more expensive and they are usually volatile (i.e. the information is lost when the power supply ceases). Therefore main memory devices are supplemented by mass memory devices both to reduce costs and to guarantee the persistence of the information which is stored on them.
At the hardware level this is a sensible and economically desirable situation. But the problem is that just reflecting this at the software level leads to much waste, for example as the Multics designers pointed out [12, 13, 14], because of the need frequently to copy programs between the main memory and the mass memory devices. (Conventional virtual memory organisation has not radically changed this, but has in fact made it worse!)
The organisation of software based on this memory dichotomy has many other disadvantages. From our present viewpoint it has led to the distinctive structuring units mentioned above. In particular there are usually several kinds of structuring unit in programming languages which match the operating system units (e.g. files and programs) and different structuring units within programs (e.g. objects in OO languages) which are not directly related to the OS level units.
Timor has chosen a different route: at the programming level the only structuring units are types and implementations. A type can define a small object as is typically found in OO languages, but it can equally be used to define a program (with potentially multiple interface methods) and even a file (also with potentially multiple interface methods). And of course there can be multiple implementations of each type.