Greetings

[Jason Marshall]

I've been working in my spare time on a system which, as time progresses,
begins to more closely resemble the TUNES system.  So I figured I'd try to
familiarize myself a little better with the goals of your project, to see if
they are in fact compatible.

My current efforts revolve around developing a portable intermediate form (LLL,
if you will) that looks a good deal like the intermediate output of an
optimizing compiler, but with copious amounts of (optional) optimization
metadata, so that load-time/runtime costs are lower.  This design is inspired
in part by a book on continuation passing style that I'm currently reading
(written by the authors of the New Jersey ML interpreter), in part by some
literature I've read about the Oberon portable format, and last but not least,
by my long love/hate relationship with Java (I've been programming in Java for
about 3 years now, and taking mental notes about what I would have done
differently for much of that time).  I am hoping to leave the LLL as
silicon-agnostic as is practically possible, while still being oriented toward
supporting some of the newer chip architectures, such as the Merced (which
supports compile-time flagging of code blocks that can run in parallel, for
instance), small places (embedded or portable systems), or even for running at
a reasonable clip on MPP machines.  So my idea of a suitable LLL is one that
represents the details of the logic flow in great detail (but perhaps missing
details like primitive value sizes), can produce extremely safe code (GC, array
bounds checking, type safety) that can enforce trust relationships on untrusted
code, is interpretable (but not geared primarily toward interpretation), and
removes some of the introspection burden from an optimizing runtime by doing a
good deal of compile-time code inspection.

As an adjunct to this work, I hope to write a 'boot-strapping' compiler that
can promote/translate well-formed Java code into this LLL form.  This choice
has been made for several reasons:
1) I am most comfortable with Java at the moment
2) Legacy support.  I would like to be able to represent a subset of legal
programs in many languages in the intermediate form, and have modules of one
language be able to call into modules in another language with only a minimal
of (preferably transparent) translation layers.  My goal is to be able to
recycle the work of others as much as possible, since I am but one person, and
then replace pieces as time permits.
3) I am still not certain what form the high-level language can/should take,
yet I want to begin making some progress on my ideas.

At some later date, I plan to produce something similar that can translate a
subset of C and C++ programs into this language (modulo certain instances of
pointer arithmetic, casting operations, etc), as well as finalizing a
high-level language/platform specification, or throwing my lot in with the
TUNES HLL.

So my biggest question at this point is why the decision was made to use an
existing human-friendly language (Forth) as the LLL for the Tunes project, as
opposed to some sort of more compiler-friendly format.

Thanks for your time,
Jason Marshall