Subject: Re: Alternatives to EVAL
From: rpw3@rigden.engr.sgi.com (Rob Warnock)
Date: 2000/04/02
Newsgroups: comp.lang.lisp
Message-ID: <8c6e54$qd44m$1@fido.engr.sgi.com>
David E. Young <youngde@mindspring.com> wrote:
+---------------
| The forms coming across the wire are indeed macro calls exported by a
| third-party package. Right now, that's the way they must remain, so the
| concensus here is that EVAL in this situation is an appropriate use.
+---------------

Well, if *all* the forms coming across the wire are indeed "macro calls",
then for safety (*and* speed!) you might want to do you own "expansion" of
the "macros". That is, simply put a function to process each form into a
hash table indexed by the "macro" keyword [car of the form]. The per-form
functions can always call EVAL on certain sub-forms if they really, really
need to, but I'll bet that most (if not all) of the time the rest of each
form is just "data" to the per-form function.

If your application *can* fit into this model...

1. It's a lot cleaner than using EVAL, since you don't have to worry
   about confusions between "macro-expand time" and run-time;

2. It's a lot *faster* than using EVAL (you don't go through the entire
   interpreter);

3. It's a lot *safer* than using EVAL, since only pre-loaded handlers
   can be called (especially if you turn off *READ-EVAL*).


-Rob

-----
Rob Warnock, 41L-955		rpw3@sgi.com
Applied Networking		http://reality.sgi.com/rpw3/
Silicon Graphics, Inc.		Phone: 650-933-1673
1600 Amphitheatre Pkwy.		PP-ASEL-IA
Mountain View, CA  94043