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: <D3n2wK.4r7@cogsci.ed.ac.uk>
Sender: usenet@cogsci.ed.ac.uk (C News Software)
Nntp-Posting-Host: bute-alter.aiai.ed.ac.uk
Organization: AIAI, University of Edinburgh, Scotland
References: <3gftki$26f@karlo.informatik.uni-kiel.de> <D36LA9.y4@cogsci.ed.ac.uk> <D3J8FB.11v@rheged.dircon.co.uk>
Date: Tue, 7 Feb 1995 16:53:07 GMT
Lines: 91
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:111514 comp.lang.lisp:16733

In article <D3J8FB.11v@rheged.dircon.co.uk> simon@rheged.dircon.co.uk (Simon Brooke) writes:
>In article <D36LA9.y4@cogsci.ed.ac.uk>, Jeff Dalton <jeff@aiai.ed.ac.uk> wrote:
>>
>>*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.
>
>Jeff, you've laboured this point, and in labouring it have convinced
>me that you are wrong (normally, I tend to believe what you say :-}).
>
>Common LISP, as a standard language, does have and does have to have
>an interpreter. 

No, that's just not true.

>How individual implementations implement that
>interpreter is up to the authors; if they choose to implement the
>interpreter by making a call to the compiler and then executing the
>result, that's up to them, but it doesn't make the process any the
>less one of interpreting language.

Compilers interpret langauge.  Very true.  And that makes them
interpreters in a sense (all things that interpret are interpreters).
But the word "interpreter" has a technical meaning as well in which
the word refers to a way of implementing a programming language.
Compilers are not interpreters in that sense and Common Lisp
implementations do not have to have interpreters in that sense.

In short, your argument commits the fallacy of equivocation
(on the word "interpreter").

>And, indeed, as your correspondent has pointed out, one feature that
>all LisP variants share is that it is trivial to build, in LisP, an
>interpreter for S expressions (it's not trivial to build one with
>exactly the same semantics as the compiler, but that's a different
>argument). So if eval isn't there, you can quickly build enough of it
>to suit most purposes.

I don't know that it's *trivial* to write an interpreter for Common
Lisp.  But Common Lisp gives you a fair amout of help.  For instance:

  * Symbol-value and symbol-function let you treat symbols as the
    names of global/special variables and global functions respectively.
    Without something like that, your interpreter couldn't access
    the variables that are used by ordinary code and it couldn't
    call the built-in functions without a big case statement (or
    equivalent).

  * Macroexpand-1 lets you expand macros.  Without something like
    that you'd have to write your own implementation of all the
    built-in macros.  And even with macroexpand-1, it's difficult
    to write a portable CL interpreter.  I'm not even sure it's
    possible.  (Look at the code-walker in PCL to see some of
    the problems.  Note too that that code-walker is not exactly
    *trivial*.)

Now, some Lisps (such as EuLisp) do not define equivalents of
symbol-value or macroexpand-1.

>If you perversely hacked enough out of LisP (any LisP) to make it
>*hard* to write an interpreter for S expressions, it would be pretty
>much useless for any other purpose, too.

That's just false.  Of course, it will be possible to write *an*
interpreter for some language written as S-exprs.  If you took out
so much that *that* was hard, you might be right.  But it can be
difficult to write an interpreter for the Lisp you're using
(e.g. EuLisp) without any such dire consequences.

>By contrast, although it's fairly easy to write interpreters for
>simple languages in AlgoL family languages, it isn't easy, for example
>to write in C an interpreter for C source code.

That's true.  But the reasons it's easier for Lisp don't have all
that much to do with the sorts of eval-is-bad-for-your-compiled-code
arguments we've seen here.  Some of the most important reasons why
it's easier to write an interpreter for Lisp-family languages are 

  * Read provides the lexical-analyzer/scanner and a bit more.
  * The rest of the parsing task (e.g. to extract the variable
    names in a "let") is usually pretty trivial (though some
    things, such as handler-case and defstruct are harder).
  * Many constructs are defined by macros so that there's less
    that must be directly implemented.

-- jeff

