Newsgroups: alt.lang.design,comp.lang.c++,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!fs7.ece.cmu.edu!kinky.eng.gtefsd.com!europa.eng.gtefsd.com!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: <D2x5Ju.8sD@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: <3fgug3$552@news.panix.com> <RFB.95Jan20150836@cfdevx1.lehman.com> <MATT.95Jan21135219@physics7.berkeley.edu>
Date: Tue, 24 Jan 1995 16:52:41 GMT
Lines: 29
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:109080 comp.lang.lisp:16479

In article <MATT.95Jan21135219@physics7.berkeley.edu> matt@physics.berkeley.edu writes:
>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.

Well, here are two that do not include eval: (1) Scheme, (2) EuLisp.
I'm pretty sure ISLisp (the Lisp being developed by ISO's WG-16) 
doesn't include eval either.  

>That's one reason why compiled lisp code is a bit unusual: the
>run-time library has to include the full interpreter.

Why would that make *compiled code* unusual?

In any case, (1) the full interpreter can be rather small, and (2)
no actual interpreter is needed (e.g. PopLog Common Lisp's eval
uses the compler -- the is no interpreter).

-- jd

