D'4 Example

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

The text in question didn't say radical changes of class, it said
any change of class.

Maybe what this really shows is that no matter what you define to be
undefined, a sufficiently clever implementor can come up with a subset
of that that clearly should have been specified to be valid for
extension rather than forever undefined.  I suppose in a way you said
the same thing by defining the set D'4 as the negation of another set.

So what does this mean?  I'm happy with your latest words for describing
things that are specified to be forever undefined, but I'm probably not
happy with some of the things that are specified that way.  Actually,
there are very few of them; ignoring duplicates, only six things are
forever undefined in 88-002 (found by searching for all occurrences
of the word "undefined"):

1. The result of attempting to store in a slot a value that does not
satisfy the type of the slot is undefined.

2. The order of evaluation of default value forms and the order of
evaluation of {\bf :initform} forms are undefined.

3. This implies that a programmer must not use {\bf change-class} inside
a method if any methods for that generic function access any slots, or
the results are undefined.

4. This argument has dynamic extent within {\bf change-class}; if it is
referenced in any way once {\bf class-changed} returns, the results are
undefined.

5. If these [print-object] rules are not obeyed, the results are undefined.

6. The results are undefined if the user attempts to change the class
associated with a symbol that is defined as a type specifier by
{\it Common Lisp: The Language.}

I think 3, 5, and 6 are questionable.  I can see reasons why implementation
dependent extensions might make sense for each of these.  If you read
the rules referred to, #5 is particularly questionable.  Are the results
undefined if a print-object method does not look at *print-escape*?
1, 2, and 4 are noncontroversial, I think.