REMF and REMPROP

["Scott E. Fahlman" <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
        more.

    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
unwary.

-- Scott