jjacobs@well.UUCP (02/22/87)
In <1270@mmm.UUCP>, Bill Rouner writes, asking for help in debugging: >(defun foo () > (let ((a '(this value set in the let))) > (eval (car '(a))))) Page 321 actually provides a nice, coherent explanation, "the form is evaluated in the *current* dynamic environment and a *null* lexical environment. Aren't the new scoping rules fun? (Disclaimer: I don't know Bill Rouner, and his msg was not set up to support any of my claims about Common LISP. Will Clinger, in <1069@tekchips.TEK.COM>, writes a very nice explanation of the problem, but then goes onto confuse things with a SCHEMEr's viewpoint of the world (valid but different). To wit: >By the way, lists are not expressions either. The general principle >is that data structures and code are entirely disjoint. Apologists >for Lisp have historically done their best to say that data structures >and code are the same, and Common Lisp retains some really bizarre >things to make that seem so, thus the confusion continues. One of the key issues that I consider distinguishes "Real LISP" from Common LISP is indeed the strong committment to the equivalence of data (meaning list structures) and code. I consider this idea one of the foundations of "Real LISP", and Common LISP intent is vague at best. InterLISP, for example, still makes a declaration of this philosophy in the manual, and it is still one of the keystones in the teaching of LISP (although whether it should be when teaching Common LISP is open to question). SCHEME does not share this philosophy. Will is correct in asserting that Common LISP does do some very bizarre things to try and keep this; the lack of a syntactical distinction between variables and symbols is absurd, as Bill's example points out. Note that there is a difference between "code and data being equivalent, i.e. list structures" and "code being data, i.e. functional objects". If variables and symbols are to be truly disjoint, then there should be a *syntactic* distinction. If code and data are to be truly disjoint (non-equivalent), then Common LISP's syntax becomes a real loser; there's no good reason not to support better syntactic constructs, and not much reason to inflict Lots of Insidiously Stack Parends on the world! Jeffrey M. Jacobs CONSART Systems Inc. Technical and Managerial Consultants P.O. Box 3016, Manhattan Beach, CA 90266 (213)376-3802 CIS:75076,2603 BIX:jeffjacobs USENET: jjacobs@well.UUCP