[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments on CLOS draft 88-2
- To: email@example.com
- Subject: comments on CLOS draft 88-2
- From: firstname.lastname@example.org (email@example.com any day now)
- Date: Fri, 8 Apr 88 13:13 est
- Cc: mike
- Comments: NOTE %acorn@oak... WILL BECOME @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. :-)
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
The following are the operations from the "Functions in the Programmer
Interface" that I think should be removed.
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