[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


In response to: Daniel L. Weinreb <DLW at ALDERAAN.SCRC.Symbolics.COM>

    In other words, either we should SPECIFY the behavior of REMF and
    friends EXPLICITLY as part of the Common Lisp definition, or we should
    admit that it is UNSPECIFIED, and implementations can do what they want,
    and users had better be aware of it.  I don't see how there can be any
    middle ground.

    In other words, we should be quite explicit about what's required and
    what's not required, and make sure it's stated clearly in the spec.

I've got no argument with this.  As these issues come up, the best thing
to do is to get each one officially clarified, one way or the other.  But
adopting official clarifications is a slow process -- absurdly slow,
unfortunately -- and there will always be some issues that we have not
yet clarified.  I was attempting to give my own view on a reasonable
philosophy for handling these things prior to an official clarification:

In cases where it is obvious that most users will have a certain model
of how an operation is going to be implemented, it is best not to go
against that model.  If there is tremendous advantage to be gained by
implementing something in an unusual way that has surprising
consequences, then it may be worth doing, but in this case the
documentation for that implementation should make a big point of
explaining what is going on (and still some users will miss that and be
screwed, because many of them tend to look only in CLtL).

I really don't care what you do in this case, since so few people will
be affected, nor do I care which way the issue gets decided when we get
around to deciding it.  The only reason I responded is that I thought I
saw an explicit argument that it is OK to do this very strange thing
because the manual does not explicitly forbid it, and that seemed like a
dangerous precedent to me.

-- Scott