Newsgroups: alt.lang.design,comp.lang.c++,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!satisfied.elf.com!news.mathworks.com!news.alpha.net!uwm.edu!vixen.cso.uiuc.edu!uchinews!news
From: Charles Fiterman <cef@geodesic.com>
Subject: Re: Interpreters (Re: Comparing productivity: LisP against C++ (was Re: Reference Counting))
Message-ID: <1995Jan24.160125.6073@midway.uchicago.edu>
Sender: news@uchinews.uchicago.edu (News System)
Organization: Geodesic Systems
References: <19941203T221402Z.enag@naggum.no> <RFB.95Jan20150836@cfdevx1.lehman.com> <MATT.95Jan21135219@physics7.berkeley.edu> <Pine.A32.3.91.950123091918.27277F-100000@swim5.eng.sematech.org>
Date: Tue, 24 Jan 1995 16:01:25 GMT
Lines: 52
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:109043 comp.lang.lisp:16475

In article <Pine.A32.3.91.950123091918.27277F-100000@swim5.eng.sematech.org> "William D. Gooch" <goochb@swim5.eng.sematech.org> writes:
>On 21 Jan 1995, Matt Austern wrote:
>
>> In article <RFB.95Jan20150836@cfdevx1.lehman.com> rfb@lehman.com (Rick Busdiecker) writes:
>> 
>> > I think that there is a common misconceptions that Lisp is an
>> > ``interpreted language''.  In fact, there is nothing to prevent anyone
>> > from building either a Lisp or a C++ in any of these configurations:
>> >  1. Compiler and interpreter.
>> >  2. Compiler with no interpreter
>> >  3. Interpreter with no compiler
>> 
>> That's not really true.  Every dialect of lisp I've ever heard of
>> includes the function eval.  Once you have eval, you have a lisp
>> interpreter; the top-level read-eval-print loop is just a frill.
>> 
>> That's one reason why compiled lisp code is a bit unusual: the
>> run-time library has to include the full interpreter.
>
>Some Lisps run all "interpreted" stuff through the compiler, and just 
>tack a simple read-eval-print loop on top of things.  This works OK,
>unless (as I have seen) the compiler is not fully reentrant.  If not, 
>and if (through the debugger, perhaps) you happen to reenter by the 
>wrong path, you lose.

There is a strong advantage to not having an intrepeter and a compiler.
Suppose one or the other has a bug. You really want to intrepret all
code or compile all code.

Self will optomize code that has been run more than 5 times. In compiling
you really need to say which information can be specialized out. That
is which parms etc won't change. Self specializes around types. If
you display a pig via a function that expects animals it builds a
version specialized to pigs. Most of the time the call at that point
will pass a pig to the display(animal) function. This results in
code that is competitive is speed and space to C++. Further the speed
and space characteristics of self are still improving so we can expect
this kind of strategy to pass C++ at some point.

We are experimenting with a system where the programmer decides what
to specialize on in the base language. This is hidden by higher level
constructs. An egrep written this way would read its arguments into
variables, freeze those variables telling the language these are now
constants and may be specialized around and then run. As functions
were called they would be compiled.

The self people discovered that compiled code is so much bigger than
source that it doesn't pay to cache it. That is you always compile
programs before running them. This really changes my thinking about
compilers.


