Subject: Re: superior(?) programming languages
From: Erik Naggum <>
Date: 1996/12/19
Newsgroups: comp.lang.lisp
Message-ID: <>

* Tim Bradshaw
| I mean, imagine if something like the CL-HTTP server let its users call
| EVAL!  If you need an evaluator for some bit of lisp, or some embedded
| language, you just write one and use that.

sigh.  I think the point is getting lost in ever more silliness.

fact 1: we can't do without `eval' in Lisp.
fact 2: just because `eval' can have negative consequences or has negative
	aspects to it, doesn't mean it's _evil_.
fact 3: reinventing wheels like `eval' is needlessly hard.

the greatest problem with applications that have their own mini-languages
is that they invariably cripple the programmer.  one of the reasons Emacs
is successful is that it uses a real Lisp language inside.  it may lack
some features we now consider essential, but it's not some "4GL" invented
by someone who doesn't even understands syntax enough to make it fit a
reasonable language model, like LL(1) or LALR, much less provide any real
set of language constructs.

an easy way to deal with mini-languages, and still save time using EVAL and
have all the interesting language features available, is to check that all
symbols in forms read are in a particular package, then _use_ only safe
symbols from some other packages in that package.

also, this is obviously not in defense of using EVAL wantonly, just because
those who argue against EVAL use such silly arguments to debunk it.  this
is not an argument in defense of letting CL-HTTP evaluate random input
code, which should be equally obvious.  I'm frankly amazed by the sheer
lack of depth and insight that those arguments portray.

there are many reasons to _want_ EVAL.  there are many reasons to want to
_limit_ the power of EVAL.  however, the people who seem to argue against
EVAL all do it under the clearly invalid presumption that EVAL has only bad
uses, that only stupid programmers use it, that only people who would want
to open a security hole in CL-HTTP, etc, would use it.  if those are the
only uses for EVAL, why would it ever be in the language?  clearly, there
was a constructive purpose to include the feature, and it is unfortunate if
the only aspects of it that people can think of are destructive.

you know where I actually _use_ EVAL?  in the read-eval reader macro!  I
need #.(complex-form) to yield the return value of the form at read time.
I also rely on eval in some software I write, which is always called from
the Lisp listener.  just like I don't foolish believe that I can dispense
with the Unix shells once I have all my applications loaded, I don't think
I can get my work done without a Lisp listener.  now, if the argument is
that people shouldn't get listeners in shipped applications, but instead
use some other user interface that for all practical purposes duplicate a
listener and evaluator, any meaning in the objections evaporates.  and
that's just what the anti-EVAL arguments do: evaporate upon inspection.

now, you guys can go on with your silly arguments against EVAL based on the
need not to open up huge security holes in CL-HTTP, but I would have
expected people to notice that there is no disagreement over such blatantly
obvious cases, and thus no need to repeat the their arguments.  unless, of
course, the point with discussing them is only to prove that you're a
card-carrying member of the eval-haters-union.  that doesn't seem very
fruitful to me.

users should be computer-friendly.