comments on CLOS draft 88-2

[mike%acorn@oak.lcs.mit.edu (mike@gold-hill.com any day now)]

Our (Gold Hill's) mail link will be disappearing shortly for about
two weeks, so I wanted to get out these last comments for 
your consideration in the next CLOS spec draft.

This has nothing to do with instance-variable names by the way. :-)

...Mike Beckerle
Gold Hill

-------------------------------------------------------------

More (but different) Comments on the CLOS specification 88-02:

I am generally pleased with the detail level of the new draft. It
nails down the semantics of CLOS much more clearly than CLtL does for
most of CL.  Nevertheless, there is one aspect of the spec that I
think should be changed before adoption as a preliminary standard.
This has to do with overspecification of the amount of dynamic
redefinition possible in CLOS programs.

All material having to do with the behavior of instances when classes
are redefined should be omitted. Common Lisp implementations should
not be required to update instances when classes are redefined.
The spec should separate "language" issues from "environment" issues
here and specify only the behavior of whole programs, not of 
environments that have been subjected to any number of redefinitions
and changes. I do not deny that it is convenient when developing a program
to have dynamic redefinition of classes; however, the common lisp spec
should be for a language first and an environment second.

In particular, the material in pages 1-15 through 1-18 of the
"Programmer Interface Concepts" part should be deleted. The behavior
of instances when classes are redefined should not be specified.
Specification of these kind of behaviors in CLtL is very weak, and 
is frequently the source of significant disagreement on the 
behavior of otherwise simple language constructs. We should not
carry on the tradition in CLtL of specifying how programs behave in
the face of redefinition or a dynamically changing execution
environment. 

The following are the operations from the "Functions in the Programmer
Interface" that I think should be removed.

UPDATE-INSTANCE-STRUCTURE
MAKE-INSTANCES-OBSOLETE 
CHANGE-CLASS,
CLASS-CHANGED
CMAKUNBOUND
CBOUNDP

The other alternative is for these symbols to name optional components
of CLOS which are not required to work in all implementations, but if
they do, they use these standard names and have this standard
functionality.