[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
REMF-DESTRUCTION-UNSPECIFIED (Version 2)
- To: CL-Cleanup@SAIL.STANFORD.EDU
- Subject: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
- From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
- Date: Fri, 30 Oct 1987 22:19 EST
- In-reply-to: Msg of 30 Oct 1987 12:31-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
- Sender: FAHLMAN@C.CS.CMU.EDU
I've wavered back and forth a few times on this in last hour, but I seem
to be converging toward MAKE-EXPLICITLY-VAGUE.
I argued before that it was treacherous, if not clearly illegal, for
implementations to play around with list cells in unexpected ways. Most
users will have a naive model of what is going on, more or less
equivalent to what is described in MAKE-EXPLICITLY-DEFINED, and it is
likely to screw these users in very subtle ways to go in and manipulate
the cells in some toher way that happens to make CDR-coding happy. But
if we give the users a sufficiently clear warning that they can't count
on the naive model, then I think it's acceptable to allow implementors
this freedom.
However, we should only go with MAKE-EXPLICITLY-VAGUE if the CDR-coding
people really think it is going to make a significant difference in the
efficiency of some real programs. I tend to doubt this, but I haven't
played much with CDR-coding and I'll yield to those with more
experience. If the added freedom only is going to make a tiny
difference, we should go with MAKE-EXPLICITLY-DEFINED, and give the
poor users one less confusing trap to fall into.
-- Scott