Paul Prescod papresco@calum.csclub.uwaterloo.ca
Mon, 05 May 1997 15:50:10 -0400

Fare Rideau wrote:
>    But this time is *eventual*:
> we don't want to port Unix to every new platform so as to run LispOS.
> Instead, *new* platforms (and progressively, old ones),
> will be supported by high-level source-to-source manipulations.
> Again, you won't ever write a Unix emulator for a cluster of MISC,
> but you can achieve wonderful performance with translated programs.

Well, as long as we are talking about some long, long term future
fantasy world where CISC and RISC are both dead then we can also presume
that the state of the art in program translators is much better. I'm
interested in the time when we have just ripped out the Unix file system
and replaced it with an object file system. How do I run TeX, my working
Prolog compiler or whatever else *then*. One day I will have a useful
system with some cool new apps written in Lisp and some cool new apps
written in C and the next day I wil be cut off from the C apps. In a
perfect world we could just agree to rewrite everything in Lisp. In the
real world we must design-in backwards compatibility. I don't see this
as a big challenge for a system of LispOS's flexibility.
> *Bzzzzt* wrong! GCC does not only generate calls, mind you,
> it also generates *code*.
> LispOS will most likely have stringent code generation rules,
> so as to allow real-time/distributed GC (ever heard about these ones?).
> GCC output obviously doesn't follow them.

My strong expectation is that LispOS will allow you to say: "this list
of bytes is a program compiled for this platform -- run it". Obviously
when you run this code it must be run in an untrusted mode and it's
objects are not collected. That isn't a big problem on any modern
"vanilla" processor platform. All of them have a "protected mode."

> > And what happens when a new version of the C app comes out? We port it
> > all over again interactively?
> >
> You seemingly haven't read my previous mail. Please do.
> I already answered this question.
> Hints: Diff, Reversibility, Morphisms, Persistence, Human Interaction.

I read all that and stared at it in disbelief. Instead of doing the
"paranoid Unix black box" once and for all, you will inject massive
amounts of effort into each porting project and even into each minor
update. You're welcome to do that but I would rather just download the
code and compile to binary.
> I also responded this objection.
> You were the only one to even imagine
> that it could be the only mechanism for porting C/C++ applications.

Well, you've come out very strongly against the "paranoid Unix black
box" so I'm not sure what alternatives you support.

 Paul Prescod