[goldman@vaxa.isi.edu: miscellaneous CLOS topics]

[Gregor.pa@Xerox.COM]

Following are parts of a message I received with comments about CLOS.
Mostly, these comments address things we have already changed, but I
thought I would send them out anyways so they would be archived and also
so that we could have saved comments from a user about :accessor-prefix
and friends being confusing.


From: goldman@vaxa.isi.edu
Subject: miscellaneous CLOS topics
Date: Tue, 06 Oct 87 18:17:02 PDT

----------------------------------------------------------------
REDEFINING CLASSES
  The way this section is worded makes it unclear to me what is supposed
to happen when I make multiple sequential changes to a DEFCLASS, creating
instances of each without accessing the "old" ones -- e.g.,

(DEFCLASS FOO ...)
 create instance F1
(DEFCLASS FOO ...)
 create instance F2
(DEFCLASS FOO ...)
  now I access F1 and F2

Are there supposed to be copies of each obsolete FOO class  around,
associated correcly with F1 and F2 so that the correct one is passed
to class-changed?

Also in this section, it states that CHANGE-CLASS preserves EQLness of
slot values for slots that are present in both the old and new class
definitions.  Why EQLness, but not EQness?

----------------------------------------------------------------
 "The initialization protocol of make-instance is not yet specified"

Is this still the case?  I imagine everyone wants to be able to do
more with INITIALIZE-KEYWORDS-AND-VALUES than initialize slots, no?


----------------------------------------------------------------
DEFCLASS
  :accessor-prefix, :reader-prefix
 The syntax calls for a SYMBOL, but the semantics appears to really just
want a string, so a string should at LEAST be acceptable if not required.

BUT, saying that
 "the names of the constructed functions are interned in the package that
is current at the time the defclass form is macro-expanded"
might make things easy on implementors, but it doesn't
do much for me as a poor application writer.  As far as I can tell,
I don't have much to say about when an implementation really decides to
macroexpand something.  I think there are (at least) two issues to
consider:
 
1) The decision here should be consistent with where DEFSTRUCT 
interns the symbols for its accessors, copier, tester.  CLtL is
suitably vague here, saying nothing under the description of :conc-name
and talking about the package at the time the defstruct is "processed"
in the other cases.

2) When I program in CommonLisp, I am used to being concerned about the
*package* setting at the time my source code is READ.  So I would like to
feel assured that I can guarantee (preferably by natural means) what
package these symbols will end up in without having to EVEN CONSIDER the
question of the setting of *package* when some implementation chooses to
"process" or "macroexpand" these forms.  

I would like to say that the new symbols must be interned in the
package that was current when the DEFCLASS form was read, but that of
course makes no sense.  Another possibility is to
really require symbols, not strings, as the defclass syntax says,
and intern in the symbol-package of the prefix symbol, but that would
not work out well in  cases where the prefix symbol turned out to be
visible by means of a USES or IMPORT, and not really be  the same package
as READ was using.  I would at the very least like to be able to
control the package in a simple way, say by permitting a more verbose
specification of the prefix options:
    (:reader-prefix "foo-" :package "MYPKG")


I wish I had a really good idea for this, but I don't.  I just feel uneasy
about having it defined in terms of MACROEXPAND time.

-------