Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site topaz.RUTGERS.EDU
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!decwrl!pyramid!pyrnj!topaz!root
From: root@topaz.RUTGERS.EDU (Charles Root)
Newsgroups: net.lang.lisp,net.lang.c
Subject: Re: Lisp to C conversion
Message-ID: <4247@topaz.RUTGERS.EDU>
Date: Sun, 1-Dec-85 20:51:39 EST
Article-I.D.: topaz.4247
Posted: Sun Dec  1 20:51:39 1985
Date-Received: Thu, 5-Dec-85 04:45:31 EST
References: <391@bcsaic.UUCP>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 20
Xref: watmath net.lang.lisp:655 net.lang.c:7268

I conjecture that you didn't hear much about Lisp to C conversion
because it isn't often done.  It is fairly common to do research using
a Lisp prototype and then build a second-generation system.  It would
be reasonable for this second-generation system to be in C.  However
the gains there are not due to conversion from Lisp to some other
language, but from using a more highly-tuned implementation.  There is
no reason to think that a simple translation from Lisp to C would gain
anything, if the original Lisp program was a sensible one.  Of course
if the original program was ill-suited to Lisp (e.g. floating point
array computations in a dialect of Lisp that doesn't do a good job
with this), then a translation might make sense.  The quality of
existing Lisp compilers seems about as good as existing C compilers.
Indeed the most widespread Lisp system that I know of (Utah's Portable
Standard Lisp) does more optimization than the most widespread C
system that I know of (various versions of PCC and Berkeley's
compilers).  The main limitation in the Lisp compilers I know about is
in dealing with heavy numerical computing.  This is not because the
compilers are stupid, but because of Lisp's nature as a typeless
language.  (Of course there are implementations that allow type
declarations.)