[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
whether random objects self-evaluate (was cleaup issues from Japan)
- To: Fahlman@C.CS.CMU.EDU
- Subject: whether random objects self-evaluate (was cleaup issues from Japan)
- From: willc%tekchips.tek.com@RELAY.CS.NET
- Date: 18 Dec 87 11:40:02 PST (Fri)
- Cc: Moon@SCRC-STONY-BROOK.ARPA, CL-CLEANUP@SAIL.STANFORD.EDU, willc%tekchips.tek.com@RELAY.CS.NET
- In-reply-to: Your message of Thu, 17 Dec 1987 21:12 EST. <FAHLMAN.12359327290.BABYL@C.CS.CMU.EDU>
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> ...)
(... (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
As better macro facilities become more universal, this is of course
becoming less of a problem.