A Conceptual Sketch of TUNES

The idea is to create a computing system without redundancy, thus being efficient, understandable, and flexible.

The TUNES HLL (High Level Language) is to be carefully crafted and coherent, with syntax options to mimic other languages.

The source code of Programs & Libraries is parsed, transformed to the internal form of the HLL (i.e., annotated expression trees), and simplified/optimized. This yields compact, platform-independent code that's efficient to process.

The Runtime Environment, which encompasses the Virtual Machine, Persistent Storage, and Garbage Collector (VM, PS, GC), executes the parsed code. It can use profiling data and user/programmer hints/overrides to choose between interpretation, just-in-time compilation (J-I-T), or static compilation.

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.

When you must use machine code, there's a "compembler". It's an assembler integrated into the HLL, featuring terse syntax and a decent amount of structure (FORTH programmers may be familiar with the concept, and there are other examples). We could do something nicer, but we'll only be using it for a few small things (like boot-loaders), and we'll have to rewrite part of the compembler for every CPU we support, so we don't want to make it unnecessarily complicated.

So, what will it take to make this a reality?

Faré, who is largely responsible for this design, suggests building an approximation of TUNES on top of Lisp. Right now, for instance, you can install the SBCL compiler, the Elephant persistence package, front-ends for other syntaxes, and perhaps a few other extensions, and you will have a crude but functional TUNESey system -- and you can expect improvement as Lisp regains popularity. This approach is immediately useful, and it provides valuable real-world experience to guide future refinements of our design.

The problem with using an existing language is that we need to tinker with the "engine" and probably rebuild it, but the "best" languages have extremely complex engines that still leave much to be desired; Lisp, Haskell, and Python fall within this category. On the other hand, Scheme, Smalltalk, and Forth have simpler engines; unfortunately, shortcomings and incompatibilities abound.

Eventually we expect to write our own compiler, runtime, and operating system. We have some collective experience in these areas, but it will be a huge undertaking. This should wait until we have a solid design and a wide variety of prototypes.