Rough Sketch of a Hypothetical "TUNES OS"

ROUGH DRAFT -- JULY 2007

1. HLM/IR - Source code is transformed into ASTs (Abstract Syntax Trees), allowing for integration with code written in other languages at the highest level possible - the "High-Level Model" or "Intermediate Representation".

2. The HLL (High Level Language) is carefully crafted and coherent, with syntax options to mimic other languages... up to a point.

3. Front-end "overlays" supplant the HLL to support "real" languages... more or less.

4. Most current languages are HLL-compatible, with one notable exception: C/C++. (The list at right is only an example, and the static/dynamic dichotomy is a bit arbitrary.)

5. ASTs are optimized and passed down to the Runtime Environment, which encompasses the Virtual Machine, Persistent Storage, and Garbage Collector (VM, PS and GC for short). The runtime can use profiling data and "hints" from the user/programmer to choose between interpretation, just-in-time compilation (J-I-T), or static compilation.

6. All of the above may sit on top of an OS like Linux or Windows, or TUNES can provide its own OS functionality. Either way, "drivers" are needed to interface with the lower level, be it actual hardware or the OS's "virtual hardware". Most driver functions can be written in static HLL code.

7. When you must use machine code, there's a "compembler". It's an assembler integrated into the HLL, offering a terse syntax and decent amount of structure. FORTH programmers may be familiar with the concept, except we'd use Lisp/Scheme syntax. We could do something nicer, but if we're only using it for the compiler back-end, boot loader, and small parts of drivers, the extra complexity is not justified.

So, how much work is involved? The HLM is essentially Lisp/Scheme, so a lot of the design work is already done, and we can borrow some library code from those language families too. We can use the Boehm GC for testing, but we'll need to write our own in conjunction with our Persistent Storage system. The compiler, compembler, parsers, and drivers will require a fair amount of effort, even if we only write front-ends for a few languages... fortunately we have a good deal of experience in those areas.

The hardest part isn't even shown here: reconciling the type systems of all the static languages. We could defer this challenge to a later version of TUNES, though.