Fw: The LispOS Project: a position paper, part 2

[ET]

I'd like to offer some constructive criticism, some of which is based
on my experience with the T compiler (Orbit).  My comments are
interspersed below.
			~jrm

----------
> From: Scott L. Burson <gyro@zeta-soft.com>
> To: LispOS@math.gatech.edu
> Subject: The LispOS Project: a position paper, part 2
> Date: Monday, 02 June, 1997 20:27

> I do understand the attraction of having "Lisp down to the metal" (a goal
the
> Lisp Machines never quite reached, by the way, because of their use of
> microcode).  But it's a massive amount of work to do well...

The LMI K-machine -- designed, built, debugged, but never marketed --
was Lisp down to the metal.  There was *no* microcode, and all but
about 64 lines of critical interrupt code (that handled the pipeline
crawlout) was written in Lisp.  The effort was in fact large, on the order
of 10 man years and 1 million dollars from initial concept to working
hardware.
(Pretty cheap, actually, but more than I have in my pocket today.)

> First, we need to select an initial hardware/OS platform.  My suggestion
for
> hardware would be the PowerMac. 

I don't own a PowerMac.  The selection of a platform will probably have to
be a pragmatic one.  I have no great love for the Intel x86 architecture,
but I have own a few x86 processors, and that counts for a lot.
 
> The next step is to begin the T port.  The Orbit back end will have to be
> modified for the target hardware, and also, probably, to integrate the
> persistence mechanism.  That's a substantial but fairly well-defined
effort.

We actually used the Orbit compiler to generate code for the K-machine.
It is much more difficult to modify the back end than advertised.  This
would be a substantial effort, but not impossible.

>  -- One of the key kinds of structure that I, at least, want to store in
the
>     form of persistent objects is source code itself.  To me, the only
LispOS
>     application that should ever be written using the traditional textual
>     representation of source code is the structure editor. 

Structure editors vs. textual editors seem to be a matter of taste.
There are a number of advantages to ensuring that the code be
syntactically correct at all points during its development, but it can
be difficult to write code in this manner.  
 
> In parallel with the effort of porting T, I would suggest it would be
> worthwhile to undertake to build a Common Lisp on top of T. 

Porting Common Lisp to Orbit was fairly easy.  The syntax environments
make it easy to convert a parsed representation of a language to
the CPS format used internally.  It would be difficult to *mix* T and
Common Lisp, however.

We could certainly do far worse than go down this path.

				~jrm