Newsgroups: alt.lang.design,comp.lang.c++,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!hookup!swrinde!pipex!uunet!franz.com!franz!smh
From: smh@Franz.COM (Steve Haflich)
Subject: Re: Interpreters (Re: Comparing productivity: LisP against C++ (was Re: Reference Counting))
In-Reply-To: aeb@lamb.saltfarm.bt.co.uk's message of 24 Jan 1995 09:42:45 -0000
Message-ID: <SMH.95Jan24231741@vapor.Franz.COM>
Sender: news@franz.com
Nntp-Posting-Host: vapor
Organization: Franz Inc., Berkeley, CA
References: <hbaker-2301950958450001@192.0.2.1> <3g2i2l$5an@lamb.saltfarm.bt.co.uk>
Date: Wed, 25 Jan 1995 07:17:41 GMT
Lines: 13
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:109154 comp.lang.lisp:16488

It's curious that so many respondents make vague claims that Common
Lisp EVAL can be implemented via compilation without actually showing
how it can be done.  It's both succinct and instructive.

If EVAL were not present in an otherwise-conforming ANSI Common Lisp,
it could be implemented thus:

(defun eval (form)
  (funcall (compile nil `(lambda () nil ,form))))

Guru wannabes might want to ponder the purpose of the last NIL.  Hint:
It's purpose is _not_ to prevent a documentation string from being
taken as a form.
