Fw: The LispOS Project: a position paper, part 2
Scott L. Burson
Mon, 2 Jun 1997 22:54:34 -0700 (PDT)
From: "ET" <firstname.lastname@example.org>
Date: Mon, 2 Jun 1997 22:15:21 -0400
I'd like to offer some constructive criticism, some of which is based
on my experience with the T compiler (Orbit).
Oh good, someone who's actually hacked Orbit.
> First, we need to select an initial hardware/OS platform. My suggestion
> 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.
Okay, well, I've put my vote in, and now we have yours. We'll just have to
see what consensus emerges (if any :-).
> 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
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.
Hmm, and Kranz (Orbit's author) left me with the impression that even he
didn't think it was all that easy.
For an x86 port it will probably be necessary to tear out the existing back
end and start over anyway.
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.
Well, to me, a key desideratum of a structure editor is that it not impose
such a requirement. It should call your attention to syntax errors, but
should not force you to fix them immediately. In short, it should retain the
flexibility of a text editor (at least to a considerable extent) while
providing a raft of new functionality.
> 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.
Why is that?