Re: Miscellaneous decisions taken or to be taken

[kempf%hplabsz@hplabs.HP.COM]

On anything not noted, I've got no opinion.

There was no mention made of compile time optimization, which I believe
I made some initial proposals on in late April or early May. I've been
meaning to revist them, will try to get to that in the next week or
so. If anybody thinks this isn't important and should be dropped, let
me know. Our applications developers are asking for it, however.

On initialization:

> 1-5, 2-44 The initialization protocol for make-instance is not yet
> specified.

I take it there was no agreement at the July meeting to a full specification? 
If so, then can someone write up the specification and post it?

PART I:

> 27 May 87 call-next-method is allowed to take arguments, however it is
>   an error to give it arguments that would change the set of applicable
>   methods.  I think we're saying this signals an error, and mentioning
>   that in some simple cases the lack of need for an error check can be
>   proved at compile time, but in general a run-time check is required.

This is fine. Do we need to further clarify the error based on Dick's
note about error signaling?

> 10 June 87 There was no response when Sonya mailed out a writeup for how
> the standard type classes are organized.  Does that mean we agreed on that?

Yes, modulo consideration of Patrick's suggested change in 
<2762944528-5369042@Jenner> for purposes of minimizing category errors. 
But I assume from the note he posted today, that he is satisfied with
Sonya's note.

> p1-12 Should defclass be allowed to change the metaclass of an existing
> class? Under what conditions should a subclass of standard-class have
> the same properties wrt instance updating as standard class?

>   Kempf says you shouldn't be allowed to change the metaclass, I think
>   because existing interfaces might not be transformable.

>   Gregor says the metaclass protocol includes a predicate function
>   that controls this.

The reason was because the representations might differ. Consider a
metaclass where the types of the slots were restricted. Instances of
classes of a metaclass which did not have those restrictions might be
difficult to update automatically. However, I think Gregor's solution of
a metaclass protocol predicate (generic) function to control this would
be sufficient.

This doesn't answer the second question, however, I'll abstain on that
one. I don't believe instance updating belongs in the language in the
first place, but rather in the environment. 

PART II:

> p1-17 "It is currently under discussion whether to provide constructs
> for giving generic functions local names."  Do we want to have this
> discussion, or to punt on this syntax. I recall we did come up with some
> reasonble semantics for a GFLET and GFLABELS. 
>
>   In July we decided to defer this.

Let's forget it for now. I've got some ideas, but I won't rehash them.

> p1-18 It is not specified whether get-setf-generic-function is a
> setf-able form.  I suggest that it be made so.  This would allow one to
> trace setf-generic-function's without having to know their names.

>   This set off a discussion of how TRACE should work that maybe doesn't
>   bear directly on CLOS.

>   Moon thinks this would be okay provided it is understood as setting the
>   mapping from a name to a generic function, not side-effecting the
>   generic function.

I've been thinking about modifications to TRACE to support tracing of
generic functions, which combines aspects of Danny's idea of making
TRACE a generic function and Moon's function specs. I'll try to get
it written up and posted by the end of the week. I think it's important
that this be addressed, since our applications developers are beginning
to express the need for the ability to trace individual methods, as
well as invocation of the generic function.

> p1-24 Should we have a call-next-method? which calls such a next method
> if it exists, else returns nil (rather than signalling an error?).  This
> seems useful rather than having to define many base methods on object.

CommonObjects had two messaging forms for this, but my general inclination
is to conform with what happens when an attempt to invoke a generic
function is made with an argument set for which there is no matching
method. Currently, an error is signalled, and I think that it should
also be for CALL-NEXT-METHOD.

>   We need to decide whether class-name of an anonymous class is nil.

Two choices are 1) NIL 2) CLASS-NAME signals an error. I vote for the
second. An anonymous class should be a class with NO name. 

> p2-19 Values: I thought we agreed that all top level forms should return
> the object.  It says here defclass "returns the name of the class"

> p2-22 Same comment as 2-19, for defgeneric-options

> 2-24 ditto for defgeneric-options-setf

>   Kempf agrees they should return the object.  Moon isn't sure, because
>   defun, defvar, deftype, and defstruct return the name.  As far as I can
>   tell every defxxx form in CLtL returns the name.  The problem is that
>   we haven't admitted that defmethod has a name.

>   In July we decided (for the previous three) to return the object for
>   all CLOS defxxx functions (being inconsistent with Common Lisp).

Additionally, it would be nice if
top level forms would also print out something at compile time. Our
applications developers are asking for some feedback about what gets
done at compile time. Maybe that's an implementation issue, though.

> p2-35 The argument order of the setf method ought to be documented here.
> Gregor proposed that new-value be the first argument.  Any problem with
> this?

>   Kempf doesn't care but his users want it to be the second argument.
>   Moon doesn't care but his users are used to it being the last argument.

>   In July we suggested making the new-value argument a required argument that
>   comes after all the other required arguments, and before the optional, rest
>   and keyword arguments.  Then we said we'd discuss it further in the mail.
>   I think we agreed that the turning of two setf argument lists into one 
>   should
>   depend only on the argument lists, and not on the gen eric function object.
>   [My notes include an illegible comment, I think it means that I still hope
>    we can keep things abstract enough that we don't have to document
>    how the two setf argument lists are turned into one.]

This sounds good to me. 

> p2-39 Arguments: "list of t's" should be replaced by "list of classes
> named t" since get-method only takes specializers, not names of
> specializers.

Yes, except I'd phrase it as "a list whose elements are the class object
for the the class named T". As I understand it, there is only one class T.

> p2-51 print-object should take a depth argument.

>   Moon strongly disagrees and points to the fourth bullet.  I believe this 
>   issue was discussed to death on the Common Lisp mailing list a few months 
>   or a year ago.
>   The point is that every single method for print-object should not have to 
>   deal with *print-level*; that's unmodular.

>   Kempf raised a consistency argument (with defstruct?) but we decided
>   not to change print-object.

I agree with Moon. Some implementors may scream (as I did), 
but it's probably not too late to correct this blemish.

PART III:

> 2-6 call-next-method dynamic versus indefinite extent

>   The document says it has dynamic extent; we need to be sure that we
>   really mean that.  In July we said "implementation flexibility, not
>   really a language thing", but I'm damned if I can figure out what
>   that means.

Yes, this needs to be resolved. See my comments below about adding
methods to more than one generic function. Although I wasn't there,
I think the "implementation flexibility" comment had something to
do with optimizing calculation of the effective method. Indefinite
extent would favor this, but dynamic extent would give more flexibility
with regard to what could be done with method objects. Indefinite
extent sounds good to me, but I'm not particularly choosy, however,
I think it should be pinned down.

> 2-9 semantic difficulties discussion was shortened for the document so much
> that much of the point was lost.  At some point we need to decide how much
> we want to standardize about this and where we want to say it; in the main
> standard or in some kind of implementation guide.

I think these semantic difficulties point out a fundamental problem with
CHANGE-CLASS. It is neither a full versioned class capability nor an
environmental undo capability, but rather a hack somewhere in between. Having
said my peace (and above, about instance changing), I'll forgoe any
further comments.

> 2-13 class-named needs a new name for consistency.  get-class would be wrong
> because the other get-xxx functions aren't name operations.  symbol-class
> is the agreed name.  It needs an environment argument.  The errorp argument
> gets in the way.  I think we agree that symbol-class should be setf'able,
> but can it only be set once for a given symbol or is it allowed to change
> the symbol-to-class-object mapping?

Why an environment argument? Since we haven't agreed to lexically scoped
class names, this would seem unnecessary. Is it to deal with the ERRORP
argument? Why do people think it will get in the way? Why not just make
it a keyword argument? A user might want to not have it signal an error
especially in metaclass programming. If whether or not it signals an
error is dependent on a (second-class) environment argument, then it
will be more difficult for a user to arrange. I think the name SYMBOL-CLASS 
is OK, and that it should be allowed to change the 
symbol-to-class-object mapping.
The important thing in CLOS is the object, and the name to object mapping
should be changable.

> 2-16 (slot-name form) should be allowed as an abbreviation
> for (slot-name :initform form).  People have been assuming this,
> but it never finds its way into the document.

>   In July we rejected this.  Since people keep assuming it, we have
>   to document explicitly that it is not allowed.

Yes.

> 2-16 boa-arglist should support &key and &allow-other-keys.

Agreed.

> 2-19 uninitialized slots should be an error to reference, not be defined
> to return an unstandardized value with no error.  I'm willing not to require
> that it signals an error if people feel that would be an undue burden,
> otherwise I prefer that reading an uninitialized slot signals an error.

I agree that it should signal an error.

>   In July we decided that signalling an error here should depend on the
>   declared safety level.  Dick has proposed terminology for this.

Dick's terminology is good. We probably need to backpatch it into the
document (it should probably be backpatched into CLtL too, but that's
not for us to decide).

> 2-57 with-slots :prefix package problem; This was discussed in the mail and
> then the ball was dropped.  What's in the document is unworkable because it
> depends on the dynamic value of *package* at macro-expansion time, but Common
> Lisp doesn't guarantee anything about when macro-expansion occurs.  Moon would
> prefer to flush the :prefix option.  An alternative
> that was discussed was to
> use symbol-package of the prefix, both here and in defclass accessor construc-
tion,
> as the package, relying on the likelyhood of prefixes always ending in delimi-
ter
> characters and exported symbols never ending in delimiter characters.

>   July: We agreed to resolve this in the mail.

I agree with Moon.

> 2-57 What does with-slots do for slots that exist in the class but don't
> have accessors, when :use-accessors t is specified (or defaulted)?

>   July: it shadows any outer bindings of the slot name, and if you
>   actually access that pseudo-variable, it signals an error.

Agreed.

> Documented holes in chapters 1 and 2 of 87-002.  We publicly promised
> X3J13 that we would finish these and have a new draft of 87-003 by the
> next meeting.

See my note of 27 July to Dick about holes in Chapter 1. I'll be replying
to Danny's comments on it shortly.

> 1-13, 1-26, 2-14 Which Common Lisp types will have corresponding classes
> is still under discussion.

Has a Cleanup Committee proposal been submitted for the type system?

> What can be done with method objects, e.g. can one method be added
> to more than one generic function?

There may be a problem if the method invokes CALL-NEXT-METHOD. This
relates back to whether CALL-NEXT-METHOD is dynamic  or indefinite
in extent. If it is dynamic, then there should be no problem, since
the binding of CALL-NEXT-METHOD is done when the method begins executing,
at the latest, or during calculation of the effective method, at the
earliest. Thus the same method object on multiple generic functions
would be no problem, since that case could be detected and establishment
of CALL-NEXT-METHOD's binding deferred as late as possible. If the
extent is indefinite, then the binding could potentially remain outside
of a particular method invocation, and so adding the same method to
more than one generic function may cause a problem.

> Ida: make-specializable seems to be missing

>   Gregor's proposal for get-generic-function will subsume this.

Wasn't ENSURE-GENERIC-FUNCTION supposed to replace this?

> Should we just flush multiple-value-prog2, as leading to more discussion
> than is warranted by its simplification of the presentation of
> define-method-combination?

Yes.

> Which symbols defined by the standard go in what package?

>   July: I think we said some will go in LISP: and some will go in CLOS: and
>   we don't know yet where to draw the line.

I think they should all go into CLOS, except those which are already in
LISP (like DOCUMENTATION) or those which are designed to replace aspects
of LISP already existing (like PRINT-OBJECT). Very few are in these categories.

> Should we flush defmethod-setf and friends in favor of function specs?
> It probably turns out they could be just in the macros and not in the
> underlying Lisp.  The big issue is standardizing where the "new-value"
> argument goes; but we may do that anyway (mentioned earlier in this file).

I think we ought to keep DEFMETHOD-SETF, but use function specs (or
something like them) as the programmer interface to TRACE. See my
comments above about TRACE.

> Should we adopt the :component-order class-option from Flavors, as a
> simple way for the user to have control of the CPL without making him
> write his own algorithm?

>   Gregor doesn't like the ability to specify constraints on the ordering
>   of classes that only apply conditionally, i.e. if those classes are
>   actually present among the superclasses.  He considers this bad style.
>   Moon volunteered to write a proposal with some examples, and we agreed
>   to resolve this over the mail.

I agree with Gregor. I think that user specified changes in the CPL
should be controlled through COMPUTE-CLASS-PRECEDENCE-LIST, or, if
the default algorithm can't make a decision. 

> The fact that symbol-function (the user callable primitive) needs to
> be split from the subprimitive for implementators that gets and sets
> the "real" function definition of a symbol.  This is so when a symbol's
> function definition is a generic function object, the "real" definition
> can be something that is easier for the implementation to call.

I don't see splitting SYMBOL-FUNCTION as an issue for the standard,
though it may be for certain implementations. Currently, most of the
PCL-derived implementations have no trouble with this.

>   July: We need to say explicitly somewhere that calling symbol-function
>   of the name of a generic function is required to return the generic
>   function object, not the "real" definition.

Yes. 

> I'm not sure if we said anywhere what happens when you call a generic
> function and there is no applicable method; I think it ought to signal
> an error.

Yes, and CALL-NEXT-METHOD should do the same. Again, we need to clarify
in the context of Dick's proposed error naming scheme.

> Clarify that because class names and classes are type-specifiers, they can be
> validly be used in THE special forms and in TYPE declarations.  We forgot this
> when we clarified that class objects can be used with TYPEP and SUBTYPEP.

>   July: agreed

Yes. Again, as mentioned in the beginning, this relates back to compile
time optimization.

> funcallable-standard-class should be documented.  It is a metaclass.
> This is what makes generic function objects funcallable.  There is a slot
> that is the actual function that gets called.

Agreed.