[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



I agree that, where a choice must be made, we should give first priority
to settling kernel-ish issues.  However, I think that the debate on
sequence functions is not detracting from more kernelish things, so I
see no reason not to go on with that.

Thanks for forwarding Masinter's note to me.  I found him to be awfully
pessimistic.  I believe that the white pages will be essentially complete
and in a form that just about all of us can agree on within two months.
Of course, the Vax NIL crowd (or anyone else, for that matter) could delay
ratification indefinitely, even if the rest of us have come together, but I
think we had best deal with that when the need arises.  We may have to
do something to force convergence if it does not occur naturally.  My
estimate may be a bit optimistic, but I don't see how anyone can look at
what has happened since last April and decide that the white pages will
not be done for two years.

Maybe Masinter's two years includes the time to develop all of the
yellow pages stuff -- editors, cross referencers, and so on.  If so, I
tend to agree with his estimate.  To an Interlisper, Common Lisp will
not offer all of the comforts of home until all this is done and stable,
and a couple of years is a fair estimate for all of this stuff, given
that we haven't really started thinking about this.  I certainly don't
expect the Interlisp folks to start flocking over until all this is
ready, but I think we will have the Perq and Vax implementations
together within 6 months or so and fairly stable within a year.

I had assumed that Guy had been keeping you informed of the negotiations
we have had with DEC on Common Lisp for VAX, but maybe he has not.  The
situation is this: DEC has been extremely eager to get a Common Lisp up
on Vax VMS, due to pressure from Slumberger and some other customers,
plus their own internal plans for building some expert systems.  Vax NIL
is not officially abandoned, but looks more and more dubious to them,
and to the rest of us.  A couple of months ago, I proposed to DEC that
we could build them a fairly decent compiler just by adding a
post-processor to the Spice Lisp byte-code compiler.  This
post-processor would turn the simple byte codes into in-line Vax
instructions and the more complex ones into jumps off to hand-coded
functions.  Given this compiler, one could then get a Lisp system up
simply by using the Common Lisp in Common Lisp code that we have
developed for Spice.  The extra effort to do the Vax implementation
amounts to only a few man-months and, once it is done, the system will
be totally compatible with the Spice implementation and will track any
improvements.  With some additional optimizations and a bit of tuning,
the performance of this sytem should be comparable to any other Lisp on
the Vax, and probably better than Franz.

DEC responded to this proposal with more enthusiasm than I expected.  It
is now nearly certain that they will be placing two DEC employees
(namely, ex-CMU grad students Dave McDonald and Water van Roggen) here
in Pittsburgh to work on this, with consulting by Guy and me.  The goal
is to get a Common Lisp running on the Vax in six months, and to spend
the following 6 months tuning and polishing.  I feel confident that this
goal will be met.  The system will be done first for VMS, but I think we
have convinced DEC that they should invest the epsilon extra effort
needed to get a Unix version up as well.

So even if MIT totally drops the ball on VAX NIL, I think that it is a
pretty safe bet that a Common Lisp for Vax will be up within a year.  If
MIT wins, so much the better: the world will have a choice between a
hairy NIL and a basic Common Lisp implementation.

We are suggesting to Chuck Hedrick that he do essentially the same thing
to bring up a Common Lisp for the extended-address 20.  If he does, then
this implementation should be done in finite time as well, and should
end up being fully compatible with the other systems.  If he decides
instead to do a traditinal brute-force implementation with lots of
assembly code, then I tend to agree with Masinter's view: it will take

I think we may have come up with an interesting kind of portability
here.  Anyway, I thought you would be interested in hearing all the
latest news on this.

-- Scott