Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: Notesfiles; site ea.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!ihnp4!inuxc!pur-ee!uiucdcs!ea!mwm From: mwm@ea.UUCP Newsgroups: net.lang Subject: Re: Re: Interpretation of Unadorned Iden Message-ID: <5400014@ea.UUCP> Date: Thu, 13-Sep-84 13:56:00 EDT Article-I.D.: ea.5400014 Posted: Thu Sep 13 13:56:00 1984 Date-Received: Tue, 25-Sep-84 02:37:19 EDT References: <2684@mit-eddi.UUCP> Lines: 26 Nf-ID: #R:mit-eddi:-268400:ea:5400014:000:940 Nf-From: ea!mwm Sep 13 12:56:00 1984 /***** ea:net.lang / mit-eddi!barmar / 5:57 pm Sep 11, 1984 */ In article <78@rlgvax.UUCP> jack@rlgvax.UUCP (Jack Waugh) writes: >If I >remember correctly, Lisp treats one as a self-quoting constant. >Lisp example: > (foo bar (bletch)) >In each example, the interpretation is to call bletch, then call >foo with "bar" as its first argument, and the value returned from >bletch is its second. You remember incorrectly. /* ---------- */ Only partly so. There is at least one LISP that sports a feature (well, they *call* it a feature) called "auto-quote". Anytime you try to evaluate an undefined atom, it gets bound to its printname. Hence (setq bar bletch) binds the string "bletch" to bar. This LISP also had "auto-cond'ing" and "auto-sequencing," which cause strange an unexpected interpretation of mis-parenthesized code. If I remember correctly, the *only* error message from this LISP system was "out of memory." Yuch.