Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!gatech!bloom-beacon!dont-send-mail-to-path-lines
From: gyro@cymbal.reasoning.COM (Scott Layson Burson)
Newsgroups: comp.lang.scheme
Subject: EVAL in Scheme
Message-ID: <9103070647.AA08672@cymbal.reasoning.com.>
Date: 7 Mar 91 06:47:54 GMT
References: <JINX.91Mar6085315@chamarti.ai.mit.edu>
Sender: daemon@athena.mit.edu (Mr Background)
Reply-To: Gyro@reasoning.com
Organization: The Internet
Lines: 52


   Date: 6 Mar 91 13:53:15 GMT
   From: "Guillermo J. Rozas" <jinx@zurich.ai.mit.edu>

   In article <1991Mar6.004022.26316@cs.ubc.ca> manis@cs.ubc.ca (Vincent Manis) writes:

      eval allows people to do to your program what Robert Morris did to
      sendmail, using exactly the same technique as he used, namely
      "smuggling" a command into a system. I regard eval as the computational
      equivalent of unprotected sex, and treat it accordingly.

   Aren't you exagerating a bit?  You are confusing the issues of
   modularity and dynamic access to the name space.  Perhaps what you are
   saying is that the application program did not hide its internal state
   sufficiently given that it was making EVAL available.

Vincent's language is colorful, but having seen what an incredible mess novices
(especially, intelligent novices) can make using macros and EVAL (especially
when they use them in combination!), I personally feel that his warning about
EVAL is not too strong.  I would go farther and suggest that all Lisp courses
should include material on the proper use of the various features of Lisp.  It
is true that Lisp is wonderfully hackable, and a fertile source of shortcuts to
get your program running, but it is also true that quick hacks have a way of
growing into systems that somebody has to maintain.

   In other words, your argument is like saying that you should use your
   own parser instead of READ, and your own output routines instead of
   WRITE (and FORMAT).  You can certainly do that, but you can get a
   program up much more quickly if you use the more powerful facilities
   available in Lisp than if you have to write them from scratch as you
   would have to in C or Pascal.

I wouldn't myself go so far as to suggest that one should always write one's
own evaluator (I once wrote a C interpreter that parsed C into list structure
which was full of macros so that I just had to call EVAL to get an expression
interpreted! -- obviously, the parser had to be specially built).  I would very
definitely say, however, that the only proper use of EVAL is in the
implementation of some sort of interpreter.  If the high-level description of
the module being written does not specify that it interprets expressions in a
language, then that module has no business calling EVAL, *period*.  In my
experience, this rule very nicely distinguishes appropriate uses from abuses of
EVAL, and I would recommend its inclusion in any Lisp course.

I don't know of any single rule that so simply and neatly guides one as to
appropriate use of macros, but one rule that does suggest itself is, Don't
violate referential transparency without somehow indicating this in the syntax.
(The indication could be something as simple as the -F convention in Common Lisp
(as in SETF, INCF, etc.); it could be by making the syntax look like an
existing well-known macro, such as LET or COND; and no doubt there are other
ways.)

-- Scott