Doing it better 1999-08-02 b
###

> You can do both at the same time: much of my work on Forth has been both
> (e.g. my work on my Forth compiler as part of my part II project, my
> recent brush with embeddable Forths). Similarly, I have used my PhD
> research to get experience in porting, writing compiler backends, literate
> programming, a really thorough knowledge of C, and use of lex and yacc
> (remember Gnat?), not to mention skeins and skeins of little bits of
> knowledge about things that have absolutely nothing to do with my
> research. Using a new tool in a simple way to do something you had to do
> anyway is an excellent way to learn the tool while still Getting Things
> Done.

Persuasive. I meant that RCS is play and Tau is work. Your argument
probably still applies.

> > Of course, part of our disorganisation is that we are not working
> > together. I think our main priority is to write and agree a proposal which
> > explains what we are trying to achieve, and how we are going to achieve
> > it. It should then break down the task into things that need to be
> > proved and implemented, and identify the important considerations that
> > affect each, and their inter-dependencies. Basically, we have to behave
> > like engineers, otherwise we'll never get anything done. Of course, that
> > might spoil the fun...
>
> I'm very much in favour of this. I have some ideas:

...which I'd like you to write up.

> 1. A portable execution environment (based on my one-file-of-C threaded
> code interpreter?)
>
> 2. A VM design (based on your recent work?)

That sounds like one idea. I'm beginning to think, based on my recent
work, that we should do something rather wierd. Forget sequential
execution of instructions; forget registers and memory; forget pointers;
forget branch instructions. The model we want is roughly an Interaction
net, which is a graph formed by joining nodes together with linear
connections. With a small number of exceptions, nodes have one principal
port, and several auxiliary ports.  Nodes can contain primitive types like
integers and floats. A redex consists of two nodes joined by their
principal ports, and it reduces to an arbitrary graph with the same
interface. The new nodes can contain integers and floats that are
calculated from those in the old nodes using simple arithmetic operations.
The small number of exceptions are things like copy and choose. There is a
back-door to invent and just-in-time compile new kinds of nodes.

This is a portable execution environment. It is easy to compile a
functional language into this model. In fact, it is related to the model
that functional langauges use anyway. Compiling C is a problem.
Implementing it is much easier than implementing a Mite-like system,
because we have substantially restricted the class of operation that can
be performed. This restriction is backed up by theory that says you can
still do pretty much anything you want.

> 3. A framework for languages (starting with my minimal
> Forth/Lisp/context-oriented-programming system, then building a system for
> specifying languages on top of that?)

Good plan. Not sure how to make it concrete.

> 4--N-1. OS/application support, which should be based on the Java AWT
> model of maximum portability by having a very thin interface to the host
> OS.

Essential.

> N. Our own OS which is really just the hardware abstraction layer needed
> by Tau on any platform. This allows "Thin Tau". One attractive option
> might be to start with Linux and gradually strip things out (in much the
> same way that developing 4--N-1 will allow us to replace the components we
> use to build Tau with bits of Tau itself (compilers, editors &c.).

Linux is an excellent base. I advocate abusing the Linux kernal to steal
its device drivers and market penetration, but to ignore the scheduler and
memory protection and stuff which we'd prefer to write in Tau. We
certainly want to diverge before the login prompt.

> The whole thing must remain open, a) because closed systems are silly; b)
> because it's much easier to develop when you can use production-quality
> "outside" tools to do the work.

Quite. Java proves that evan an "open" system can be defended vigorously
if it becomes necessary.

Alistair