Newsgroups: alt.lang.design,comp.lang.c++,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!pipex!uknet!festival!edcogsci!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Subject: Re: Interpreters (Re: Comparing productivity: LisP against C++ (was Re: Reference Counting))
Message-ID: <D36LA9.y4@cogsci.ed.ac.uk>
Sender: usenet@cogsci.ed.ac.uk (C News Software)
Nntp-Posting-Host: bute.aiai.ed.ac.uk
Organization: AIAI, University of Edinburgh, Scotland
References: <RFB.95Jan20150836@cfdevx1.lehman.com> <D2x55L.8Ht@cogsci.ed.ac.uk> <3gftki$26f@karlo.informatik.uni-kiel.de>
Date: Sun, 29 Jan 1995 19:10:56 GMT
Lines: 83
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:109820 comp.lang.lisp:16547

In article <3gftki$26f@karlo.informatik.uni-kiel.de> wg@informatik.uni-kiel.d400.de (Wolfgang Goerigk) writes:
>In <D2x55L.8Ht@cogsci.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) 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
>   > >
>   > >The fact that most Lisp implementations are of type 1 and most C/C++
>   > >implementations are of type 2 does not reflect anything fundamental
>   > >about the languages themselves, but rather about the decisions made by
>   > >people who chose to build implementations of the languages.
>
>   > Since Lisp interpreters are usually fairly easy to write, that
>   > may be one reason why Lisps tend to include interpreters (even
>   > if they have a compiler as well) while Cs and C++s don't.
>   > However, Common Lisp interpreters tend to me more complex than
>   > those of simpler Lisps, which may have had an effect on
>   > implementation techniques (e.g. so the interpreter and compiler
>   > can share more code).
>
>   > In any case, I think your point is a very important one, and not only
>   > when it comes to macros.  Many of the things people think of as 
>   > properties of langauges are actually due in large part to implementation
>   > traditions instead.  C programmers often (usually?) know the kind of
>   > code they'll get from various constructs, and they know this even
>   > though the language definition allows things to work very differently.

>Of course, the reflective nature (e.g. EVAL) of at least Common Lisp
>is due to implementation tradition. However, it is part of the
>language definition and of course is a fundamental language property
>distinguishing Lisp from other languages. The ongoing discussion tends
>to hide the difference between interpretation used to implement a
>language and the __reflective__ nature of functions like EVAL beeing
>part of the programs itself.

*Lisp* does not have to include eval.  Neither EuLisp not Scheme
have an eval, for instance.  (Eval is not part of those language
definitions.)  But even in Lisps that do include eval (such as
Common Lisp), it's not necessary to have an interpreter.  Everything
can be done by a compiler.  My point above was that *languages* in
the Lisp family do not have to be interpreted, even though it's
common for *implementations* to be or to include interpreters.

>EVAL is not just an interpreter in the above sense, although it is
>fairly easy to write one using EVAL, e.g. 
>
>     (print (eval (read)))
>
>with some prompting stuff. 

I wouldn't call that in interpreter.  I'd call it an interative
top level or a read-eval-print loop.  No interpreting need occur,
since all the evaluation can be done by compiling (and then executing
the resulting code, of course).

>As an exercise we could try to eliminate
>EVAL using some other reflective features of Lisp. LOAD has been
>mentioned already but there are more, and of course, COMPILE is one,
>too.

>However, it is not possible to write an EVAL function like that of
>Common Lisp to be part of the user program in C or C++, interpreting
>or even changing its own code, because those languages are not
>reflective. As a matter of fact, this is not only due to
>implementation tradition using compilers.

I'm not sure what you have in mind here when talking about Lisp
being "reflective".  You could write an eval in C or C++ that
interpreted (or changed -- though I'm not sure why you include
that) its own (source) code.  (A Common Lisp eval could only
interpret or change source code too.)

The difference between most Lisps (including Common Lisp) and
C / C++ is that global variables correspond to symbols.  So
you can, for instance, read in the symbol F and then access
or assign to the function definition of F.  So the root issue
is the presenece in Common Lisp of symbol-function and
symbol-value.

-- jd
