[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Cleanup issues from Japanese technical working group
- To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
- Subject: Cleanup issues from Japanese technical working group
- From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
- Date: Thu, 17 Dec 1987 21:12 EST
- Cc: CL-CLEANUP@SAIL.STANFORD.EDU
- In-reply-to: Msg of 17 Dec 1987 20:35-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
- Sender: FAHLMAN@C.CS.CMU.EDU
It's not true that CLtL says nothing about this; the bottom of page 54
in the English edition says evaluating any other object is an error.
I don't know what the rationale was; unless somebody knows, we can't easily
provide it in the standard!
At Symbolics we pondered this for a while and settled on the idea that
only objects of type (OR CONS SYMBOL) do anything special when evaluated,
and all other objects evaluate to themselves. We haven't had any problems
as a result of this.
I remember some of the discussions on this issue (though I no longer
remember which side I was on -- scary!). A number of people wanted to make all
objects other than Conses and Symbols be self-evaluating; a number of
other people didn't want to close off the space of possible extensions
in this way. The latter group won.
In retrospect, it seems clear that this was a mistake -- nobody has used
the added freedom as far as I know, and the need to quote such things as
vectors has definitely led to confusion among new users and an
occasional spurious bug report. I'd support a move to change this, so
that we could all assume self-evaluating objects when we're writing
portable code. Since "it is an error" to eval objects of miscellaneous
types, implementations are legally free to adopt the self-eval
convention, but I would argue that it is a bit treacherous for their
users if they do, since the local users will be in for a nasty surprise
whenever they move to a system that doesn't use this convetion.
On the Quit issue, I think that Masinter has suggested the right way to
handle this: ed, dribble, and friends should be suggested names for
certain environment-related operations, but nothing more. The standard
would explicitly say that these environment functions may or may not
exist in any given implementation, and that what they do will vary from
one environment to another. CLtL currently says a bit too much about
some of these things, which causes people to want to say even more.
-- Scott