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.