[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Miscellaneous decisions taken or to be taken
- To: Common-Lisp-Object-System@SAIL.STANFORD.EDU
- Subject: Miscellaneous decisions taken or to be taken
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 6 Aug 87 22:30 EDT
- In-reply-to: <870727224638.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
I have updated my file of miscellaneous decisions taken or to be taken,
based on my notes from the meeting we had in July and on mail received
in response to the last time I mailed this out (about two weeks ago).
If anyone doesn't see their response included, or thinks their favorite
issue is missing, please let me know and I will apologize for my error
and add it. I hope that we can use this file to help drive progress.
The major issues of object creation and class redefinition are not in
here, being handled individually.
The rest of this message is the file. Page separator characters don't
seem to go through, so I have replaced each with 16 equal signs.
This page is things that I think we agreed that we had decided
after the March meeting and before the July meeting.
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.
Specify precisely the type of error signalling.
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?
Patrick agrees 7/29/87. It's in the document file now.
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, but
consistent within CLOS). The document file has been updated.
This page is a list of issues on which we should make decisions,
brought up by Danny. Where I saw responsive answers in the mail
(there were very few) I have edited them in. I've removed comments
that were purely editorial comments on the document.
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, because
the representations might differ and existing instances might not
Gregor says the metaclass protocol includes a predicate function
that controls this, and Patrick and Jim agree.
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.
2 Aug 87 RPG offered to write a proposal.
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. Kempf is working on a proposal.
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. See class-name discussion below (2-13).
p1-19 "... Common Lisp be modified to include the following semantics
for quote in a type specifier:
(deftype quote (object) '(member ,object)))"
Has any proposal for this been given to the cleanup committee?
Yes: ISSUE: TYPE-MEMBER-SINGLETON, Proposal TYPE-MEMBER-SINGLETON:QUOTE
It hasn't really gone through the mill yet, though.
In July Moon volunteered to make sure this happens.
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.
Common Lisp reserves question mark for the user; this could be named
CALL-NEXT-METHOD-OR-NIL, or something like that.
Kempf: signalling an error is sufficient, this probably isn't needed.
In July we wondered whether there should be a way to get a list of
the remaining methods. I'm not sure what operations on that list,
besides checking its length, would be permitted.
2-13(?) The generic function class-name is not written up. It returns a
name for the class as argument. I believe that (class-name class)
should be setf-able. Can a class have more than one name? Should
class-name then return a second argument -- the rest of the names this
class is known by.
Kempf thinks the class name should be changeable and only one name
at a time should be allowed. Moon agrees.
See additional discussion of class names below (2-13).
We need to decide whether class-name of an anonymous class is nil or
signals an error.
The concensus seems to be to return nil.
p2-26 I believe that short form method combination ought to be a macro
in the standard library, and documented there, not in the basic
principles. I think the standard combinations :append, :and, :or, ...
should also be put in the standard library too.
Kempf agrees. Moon can't have an opinion until he knows what this
library is and whether it's going to be as much of a joke as the
Common Lisp Yellow Pages.
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
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 generic 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. But maybe it means that
we will document it, but still have defmethod-setf so that most users
don't have to think about it (only users making setf methods "directly").]
p2-39 Arguments: "list of t's" should be replaced by "list whose elements are
the class named t" since get-method only takes specializers, not names of
p2-46 Last line: If call-next method is extended ..." I see no reason
for additional keyword arguments.
Moon doesn't remember the issue. It may have been consistency; if call-next-method
can specify the arguments, then so can make-method-call. You need one keyword
argument to specify the methods and another to specify funcall versus apply.
It could also have been that call-next-method would be implemented in terms of
make-method-call, and therefore would need to be able to specify the arguments.
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.
p2-54 slot-missing should be documented
It's a generic function of a class, an object, and a slot name.
I suppose the default method signals a condition of the same name?
Gregor will propose the details.
This page is a list I made in March, keyed by page numbers in the document.
Issues mentioned earlier, or that have since died, have been removed. I've
removed comments that were purely editorial comments on the document.
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 (optimizing calculation of the effective method?).
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.
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 to deal with the issue of
compile environment versus run-time environment. The errorp argument gets in
the way, because it's an optional argument--we could get rid of it, or we
could make both arguments keywords. 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?
Kempf: Need consensus on a general solution of the compile environment
issue before fixing individual functions such as symbol-class.
The symbol-to-class-object mapping should be changeable.
Bobrow: symbol-class should be setf'able.
Gregor: setf'able. Issue is consistency of symbol-class with class-name.
1) No class-name. 2) No consistency. 3) class-names returns a list of
names and setf of symbol-class maintains it. 2 is unreasonable.
I like 1 but 3 is good too.
(setf (class-named 'n1) nil) is how you undo the binding.
Note that this same analysis applies to generic-function-name and
setf of symbol-function and get-setf-generic-function.
Bobrow: I like 3.
Moon: class-names would need an environment argument too.
I guess any of these is okay but 2 is how everything else works.
I don't like undoing the binding by setting to NIL (CL Cleanup
may propose a general mechanism for undoing named definitions).
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.
2-16 boa-arglist should support &key and &allow-other-keys.
2-18 default boa-arglist to be specified
2-18 (:accessor-prefix nil) is not a good way to say "use the slot names
as the accessor names". We need to fix this.
We could add another option, or remove the whole prefix feature, and
require accessor names always to be listed explicitly.
In July we agreed to discuss this in the mail.
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.
In July we decided that signalling an error here should depend on the
declared safety level. Dick has proposed terminology for this.
Kempf: it should signal an error.
2-38 need a way to recover documentation of a method-combination type
July: do this by adding a new value for the second argument to DOCUMENTATION.
But the whole writeup on DOCUMENTATION is screwy, and we need a new proposal.
When the CL-Cleanup subcommittee finishes cleaning up the concept of
"definition" (I think it's waiting for Masinter to propose something)
then DOCUMENTATION should follow.
2-40 get-setf-generic-function needs an errorp, but it and ensure-generic-function
should be subsumed by get-generic-function which would do all the right things.
We seem to have lost Gregor's proposal for get-generic-function.
Or was it called ensure-generic-function?
Gregor promised to mail out the proposal.
2-42 make-generic-function should be deleted, redocumented as a class
that can be given to make-instance
2-45 make-method should be deleted, redocumented as a class
that can be given to make-instance
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 construction,
as the package, relying on the likelyhood of prefixes always ending in delimiter
characters and exported symbols never ending in delimiter characters.
July: We agreed to resolve this in the mail.
Kempf, Moon: Flush :prefix.
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.
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
1-5, 2-44 The initialization protocol for make-instance is not yet
1-13, 1-26, 2-14 Which Common Lisp types will have corresponding classes
is still under discussion.
Document has been updated in draft.
Need Cleanup Committee proposals for fixes to the type system.
2-7, 2-46 [The proposed extension to call-next-method has been accepted.]
This may not have been put into the document yet.
2-41, 2-48 [Perhaps we can adopt the condition signalling system now.]
What can be done with method objects, e.g. can one method be added
to more than one generic function?
Kempf: There may be a problem if the method invokes CALL-NEXT-METHOD.
[I wasn't able to understand his description of the problem -- Moon]
Ida: make-specializable seems to be missing
Gregor's proposal for ensure-generic-function will subsume this.
Moon: method arglist congruence still doesn't satisfy me. I have some
ideas about this but unfortunately have not managed to pull them together.
To be resolved as part of the initialization protocol discussion.
Should we just flush multiple-value-prog2, as leading to more discussion
than is warranted by its simplification of the presentation of
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.
The top level macros and functions should be part of LISP.
The internal functions specified for the sake of metaclass programming
can reside in CLOS.
If CLOS is an optional part of CL, are the symbols in the LISP package
even when the option is not present? Probably.
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).
What about the setf of values extension that Common Lisp provides syntactic
space for but does not currently prescribe?
Kempf: I think we ought to keep DEFMETHOD-SETF, but use function specs (or
something like them) as the programmer interface to 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.
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.
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.
Kempf: I don't see splitting SYMBOL-FUNCTION as an issue for the standard,
though it may be for certain implementations.
Moon: Right, the only standardization issue is making sure
SYMBOL-FUNCTION returns the generic function object, not something internal.
See earlier discussion of class-names (2-13), which affects symbol-function.
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
Gregor volunteered to send some mail about this.
CALL-NEXT-METHOD with no more methods should do something similar,
but not identical.
We could call a generic function like NO-MATCHING-METHOD, but it would
be better to signal a condition (assuming conditions are adopted into
Common Lisp). The error message should give some information about
the classes of the parameters, to help debugging.
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.
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.
I think Gregor volunteered to propose details.
Need to be able to get at the obsolete classes associated with a class,
to put methods on them.
Patrick has proposed.
Need discussion of how instances are transformed one step at a time
when a class has been redefined multiple times.
Not all of the "corrections and amendments" handed out at the March 1987
X3J13 meeting in Palo Alto have been put into the document yet. The
corrections are in but the amendments and the revised explanation of slot
inheritance are awaiting review by the group.
Kempf 29 Jul 87: 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 revisit them.
2-30: Note the third paragraph on p.2-30 of 87-002, speaking of signalling an
error when the arbitrary order of two methods affects the result. I suggest
that this error be mandatory instead of optional.