[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
REMF and REMPROP
- To: common-lisp@SAIL.STANFORD.EDU
- Subject: REMF and REMPROP
- From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
- Date: Thu, 05 Feb 1987 18:06:00 -0000
- In-reply-to: Msg of 4 Feb 1987 20:02-EST from David L. Andre <DLA at DIAMOND.S4CC.Symbolics.COM>
- Sender: FAHLMAN@C.CS.CMU.EDU
In reply to: David L. Andre <DLA at DIAMOND.S4CC.Symbolics.COM>
Destructive operations should do what they are documented to do, and no
If this is the case, then they should be documented to do something.
Consider: I can think of two plausible implementations of REMPROP which
"only do their contract". The first one is the zetalisp version which
requires that the top-level list be spliced in a specific fashion. The
second would be a function which pulled all the elements of the plist
after the removed property pair forward, and set the CDR of the tail
NIL. I will argue that both of these functions "do what they are
documented to do, and no more". However, programs which share property
lists would behave differently in the two hypothetical implementations.
So my question is, if this is allowed, why can't I wreak my own havoc
with the spare conses, which has the same effect?
In my view, it isn't allowed, or at least it shouldn't be done this way.
If you want to think up bizarre ways of implementing things, argue that
these are legal because the book doesn't explicitly forbid them, and
then use these things to justify "wreaking havoc" because the book
doesn't forbid that either, then I guess your position is defensible, at
least. I can't point to any particular sentence in CLtL that says that
what you propose to do is illegal. I just think that it violates the
reasonable expectations of the users; most will assume that two backbone
cells are snipped from the list without any further reordering unless
the manual warns them that something more complex might be going on.
It's good design philosophy for an implementor not to exploit loopholes
in the spec in ways that will screw users. As I said before, in this
particular case, any user who gets in trouble was skating too close to
the edge anyway, but I still don't think you should set traps for the