Re: Common Lisp for SUNS

[franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)]

  I'm sorry if you got the impression that I was criticizing the authors
of KCL.   I'm sure that they are excellent programmers and have
developed the best possible C-based Lisp system.

  What I do still question is the use of C as the intermediate language for a
Lisp compiler.   I would like the put this question to Professors Yuasa
and Hagiya, "If your job was to write the *best possible* Lisp system
for a given machine, and you were allowed a reasonable amount of time
to do so, would you choose C as the intermediate language or would you
go directly to the machine language?"    My answer would be of course to
go to machine language and I suspect that they would agree.  However, if the
goal is to write a Lisp that is a portable as possible and where
efficiency is important only as long as it doesn't get in the way of
portability, then using C may be a good idea.

  C was a good match for the PDP-11 but on every machine since then it
has been a compromise, with the nice new features of the each
architecture frequently being inaccessible to the C programmer
(e.g. the tagged add's and the global registers of the sun4).  If your
goal is the *best possible* Lisp then you should use all the
features of the architecture that are appropriate for Lisp.  [Your
conclusion on the uselessness of global registers in the sun4 
only looked at the first-order effects.  Yes, you don't need a global
pointer if you use direct linked calls, however the use of
a global pointer gives one position independent code which permits the system
to have a copying garbage collector (without maintaining relocation tables)
which has important benefits in paging and so on and so on]

    You said that your compiler does well when everything is declared and
speed=3 and safety=0.  This situation occurs in less than 1% of the code
I write.   I believe that Lisp has to work well in the mode where
the user just wants the speedup the compiler provides and doesn't
want to lose the interactive detection of errors he would get from
running the code interpreted.   If the Lisp does a good enough job at
inlining type checks the user will be satisfied with the performance
and won't even crank up the speed and lower the safety.    Inline
type checking is a case where there are clever hacks (unexpressible in C)
than implementor can use. 

  Yes, it does take time to port Lisp to a machine if you have to 
study the architecture in detail and write in machine code.
However, computer manufacturers are convinced that Lisp is an important
language to offer so typically they supply machines to Lisp implementation
companies well before the the machines are introduced to the public.
Thus a C-based implementation won't 'get to market' that much
earlier (if any earlier).  As for architectures that existed before
Common Lisp 'took off', there are still a few important ones
without 'native' Lisp ports but that number is shrinking and will be
close to zero in six months to a year.

  I don't mean to put down anyone or any company.  Thinking back I realize
that I've spent a third of my life implementing Lisp on stock
hardware machines, so I guess that I've developed some strong opinions during
that time.   Sorry for being so longwinded.


John Foderaro
Franz Inc.