Issue: EVAL-OTHER (Version 1)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

Here's the message I was thinking of (thanks, Richard).  By the way,
I don't buy Will's argument...I don't think making evaluating a
function or a closure an error will detect a very large fraction
of the errors typically made with backquote.  I know it would detect
almost none of the errors I make, which are usually to evaluate
something at the wrong time rather than to evaluate something that
should not have been evaluated at any time.  Just some input.

Date: Mon, 7 Mar 88 18:44 EST
 From: Richard Mlynarik <Mly@JASPER.Palladian.COM>

    Date: Mon, 7 Mar 88 16:25 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    I remember this issue being discussed only a few months ago on either
    Common-Lisp or CL-Cleanup.  I think somebody had some reasons to oppose
    this proposal, but I don't remember finding them convincing.  Sorry I
    don't remember any of the details, I mention it because perhaps this
    will stimulate someone else's memory.

To: Fahlman@C.CS.CMU.EDU
Cc: Moon@SCRC-STONY-BROOK.ARPA, CL-CLEANUP@SAIL.STANFORD.EDU, 
    willc%tekchips.tek.com@RELAY.CS.NET
Subject: whether random objects self-evaluate (was cleaup issues from Japan)
In-Reply-To: Your message of Thu, 17 Dec 1987  21:12 EST.
	     <FAHLMAN.12359327290.BABYL@C.CS.CMU.EDU>
Date: 18 Dec 87 11:40:02 PST (Fri)
 From: willc%tekchips.tek.com@RELAY.CS.NET

Let me report on the Scheme situation and my experience.  As in Common Lisp,
it is "an error" to evaluate a random object, but most implementations
extend the language by allowing at least some random objects (notably
the empty list, since only a few implementations yet distinguish the empty
list from #f) to evaluate to themselves.  MacScheme allows all random objects
to evaluate to themselves, but unlike Symbolics I have found this to be
a (minor) problem, and I recommend that implementors avoid my mistake.

The problem: In writing a macro using backquote I sometimes leave out a
quote mark, insert an extra comma, or put a comma in the wrong place.
Then an expanded macro can look like 

    (... #<PROCEDURE> ...)

when I wanted it to look like

    (... '#<PROCEDURE foo> ...)

or

    (... (lambda (...) ...) ...).

I would like to get an error message from the incremental compiler, because
I never deliberately write code with unquoted procedures, but with
self-evaluating procedures no error will occur until the expression is
executed, and then the values seen in the debugger can seem very strange.
In my code, this kind of macro bug almost always shows up as a procedure
that was closed in the wrong environment, but if I'm unlucky the incorrect
procedure will pass control to an altogether unfamiliar part of the system
before trapping on some unrelated error such as taking the car of the empty
list.

As better macro facilities become more universal, this is of course
becoming less of a problem.

Peace, Will