Subject: Re: superior(?) programming languages From: Erik Naggum <news@naggum.no> Date: 1996/12/19 Newsgroups: comp.lang.lisp Message-ID: <3059953015972831@naggum.no> * 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. #\Erik -- users should be computer-friendly.