[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, 20 Aug 87 13:10 EDT
I have updated my file of miscellaneous decisions taken or to be taken,
based on mail received in response to the last time I mailed this out
(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 as
part of the agenda for the September meeting. Let's try to resolve any
of these issues that can be resolved through the mail before that meeting.
Also, if I've marked an issue as agreed but you disagree, please speak up
now.
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 file reflects Moon's understanding of the status of various CLOS issues,
concentrating on the more minor issues. The goal is to make sure that nothing
is overlooked, and especially to make sure that issues that have been brought up
and resolved are not forgotten before they get into the document. I've removed
most comments that were purely editorial comments on the document. I also
haven't tried to keep track of all the purely meta-object issues. I've edited
things to be as brief as possible.
All page references are to the 87-002 version of the CLOS document.
The file is divided into pages as follows:
0. This page of general outline
1. Documented holes in chapters 1 and 2 of 87-002
2. Things that have been already decided (but may not be in the document yet)
3. Issues with no apparent remaining disagreement
4. Small issues needing discussion
5. Issues whose status is unclear, maybe to be tabled
6. Big issues needing discussion, each on its own page
================
DOCUMENTED HOLES IN CHAPTERS 1 AND 2 OF 87-002
We publicly promised X3J13 that we would finish these holes and also have a new
draft of 87-003 by the next meeting (October).
1-5, 2-44 The initialization protocol for make-instance is not yet
specified.
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.]
================
THINGS THAT HAVE BEEN ALREADY DECIDED (BUT MAY NOT BE IN THE DOCUMENT YET)
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 The document has been updated with a discussion of how the standard
type classes are organized.
8/9/87 Gregor promised to draw a picture.
2-16 (slot-name form) is not allowed as an abbreviation
for (slot-name :initform form). People have been assuming this,
we have to document explicitly that it is not allowed.
The decision to reject (slot-name form) was made at the July meeting.
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.
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
In July we decided to return the object for all CLOS defxxx functions (being
inconsistent with Common Lisp, but consistent within CLOS). The document file
has been updated.
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
specializers.
Agreed.
2-42 make-generic-function should be deleted, redocumented as a class
that can be given to make-instance
July: Agreed
2-45 make-method should be deleted, redocumented as a class
that can be given to make-instance
July: Agreed
2-54 in the Amendments: 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
================
ISSUES WITH NO APPARENT REMAINING DISAGREEMENT
1-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?
Gregor says the metaclass protocol includes a predicate function that controls
whether the metaclass can be changed, which depends on whether the
representations differ and existing instances might not be transformable.
Some cross-reference to this should be added to the documentation of DEFCLASS.
1-15 to 1-22 Several errors in the formal description of class precedence and
method combination, pointed out by Jim Kempf on 4 August and 27 July, need to be
corrected. These are editorial changes only, that is, they make what the
document says conform to what I believe our intent to have been.
2-35 The argument order of the setf method ought to be documented here.
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. It's important that this depends only on the two
lambda-lists, and not on any context such as the generic function object.
We still have defmethod-setf so that most users don't have to think about it
(only users making setf methods "directly").
The rule, carefully worded so as to work in the face of implementations with
non-standard lambda-list-keywords, is that the setf-lambda-list is inserted
into the normal lambda-list immediately after the last parameter-specifier
that precedes &optional, &rest, &key, or &aux. This is implemented by the
following function (should it be standardized as part of CLOS?):
(defun combine-setf-lambda-lists (lambda-list setf-lambda-list)
(do ((ll lambda-list (cdr ll))
(tail lambda-list))
((or (null ll) (member (car ll) '(&optional &rest &key &aux)))
(when (null ll)
(setq tail nil))
(append (ldiff lambda-list tail) setf-lambda-list tail))
(unless (member (car ll) lambda-list-keywords)
(setq tail (cdr ll)))))
What about the setf of values extension that Common Lisp provides syntactic
space for but does not currently prescribe? We're not going to allow that for
setf of generic functions.
2-50 Should we flush multiple-value-prog2, as leading to more discussion than is
warranted by its simplification of the presentation of define-method-combination?
Kempf: Yes.
2-51 It has been suggested that 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.
2-54 slot-missing should be documented in chapter 2
Gregor:
slot-missing is a generic function which takes three required
arguments and an optional fourth argument. The three required
arguments are the class of the object, the object and the name of the
slot. The fourth argument is the new value for the slot if
slot-missing is being called by setf of slot-value. This set of
arguments allows people to define methods on the metaclass for
handling slot-missing. For example, a low performance implementation
of dynamic slots could work this way.
(defmethod slot-missing ((class dynamic-class) obj slot
&optional (nv nvp))
(if nvp
(set-dynamic-slot obj slot nv)
(get-dynamic-slot obj slot)))
The default method on slot-missing signals an error of the same name.
Symbol-function (the user callable primitive) needs to be split from the
subprimitive for implementors 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.
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.
================
SMALL ISSUES NEEDING DISCUSSION
1-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, but in August
Moon said he didn't like it and we should use MEMBER in parameter
specializers instead.
1-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. What operations on that list should be
permitted?
- checking whether it's nil gives the desired feature
- checking its length
- doing something with list elements (presumably method objects)
- modifying the list is clearly out
- does the list have dynamic or indefinite extent?
This may be expensive enough that it can't substitute for
CALL-NEXT-METHOD-OR-NIL.
I think we're awaiting proposals on these two issues, as well as a
concensus on whether we need these features.
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.
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-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.
Gregor: What if by the time you actually run the body of the method, the slot
has an accessor? It all hinges on exactly when macro-expansion time is and
that is not specified.
There are two issues here:
(1) Exactly when is the set of names scoped with with-slots determined?
(2) Exactly when is the presence or absence of an accessor for a name
determined?
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]
Gregor: I believe it should signal an error to attempt to put a method on more
than one generic function. My model of this is that if you want to do
something like that, you can take one function, use it as the method function
of multiple methods, each of which would be on a different generic 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
an error.
Gregor:
This is a generic function like slot-missing. There is a generic
function NO-MATCHING-METHOD which is called with the generic function
as the first argument and the arguments to the generic function as
the remaining arguments. This allows people to define a method to
handle the no matching method case either on the class of the generic
function or on the individual generic function. The default method
for no-matching-method signals an error of the same type.
The error message should give some information about
the classes of the parameters, to help debugging.
CALL-NEXT-METHOD with no more methods should do something similar,
but not identical.
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.
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.
What does type-of return when applied to an instance of an anonymous
class?
Returning NIL is not valid by CLtL's definition of TYPE-OF.
The choices are either to return the class object itself or
the name of some superclass that has a name, T if necessary.
================
ISSUES WHOSE STATUS IS UNCLEAR, MAYBE TO BE TABLED
1-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
reasonable semantics for a GFLET and GFLABELS.
In July we decided to defer this.
2 Aug 87 RPG offered to write a proposal.
2-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.
2-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.
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?).
Gregor: I am pretty sure what we meant was we didn't want to have to worry
about the case where someone returns a closure that includes a call
to call-next-method, and then redefines the class or method structure
so that the closure would have to call different 'next methods'.
Moon: Oh, so this is different from extent, because they could do that
redefinition before the method returns. So either we should say it
captures the set of next methods at a particular instant, or it's
undefined what happens if you redefine.
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.
[no response to this so far, Moon should propose I guess]
2-16 boa-arglist should support &key and &allow-other-keys.
2-18 default boa-arglist to be specified
Status depends on whether object-creation proposal includes constructors.
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.
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 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.
================
PREFIXED SYMBOL NAMES
These two issues appear to be related.
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-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 likelihood 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.
Gregor: I like the prefix option, although I agree that this is a serious
problem.
================
ENSURE-GENERIC-FUNCTION
A constellation of issues surrounding the mapping from generic function
names to generic function objects. This seems to be awaiting a proposal
to pull it all together.
1-18, 2-40 It is not specified whether get-setf-generic-function is setf-able.
Gregor: make it setf'able, it's just like symbol-function. Maybe
rename it to symbol-setf-generic-function?
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).
Good reason to rename it to symbol-setf-generic-function.
This set off a discussion of how TRACE should work that maybe doesn't
bear directly on CLOS. Kempf is working on a proposal.
2-40 get-setf-generic-function needs an errorp, but it and get-generic-function
should be subsumed by ensure-generic-function which would do all the right things.
Gregor:
I propose that we keep get-setf-generic-function, but that we rename it to
symbol-setf-generic-function. In addition, I propose that we do the
following:
ensure-generic-function, add-named-method and any other CLOS
function that takes the name of a generic function as an argument
can also take a list like (SETF <symbol>) which means the
setf-generic function for that argument.
I propose that ensure-generic-function do basically what
defgeneric-options and defgeneric-options-setf used to do except that
ensure-generic-function would be a function (that is it would
evaluate its arguments). This isn't a problem since
defgeneric-options didn't take any &body arguments anyways. The real
thing that needs to be worked out here is what happens if the generic
function already exists, but is different in some ways than the
description in the arguments to ensure-generic-function.
The relevant options (referring to 2-42) seem to be:
:lambda-list -- method congruence issue
:generic-function-class -- covered below
:method-class -- are existing methods mutated?
Moon doesn't see any problem with changing these options:
:argument-precedence-order
:declare
:documentation
:method-combination
Gregor's e-g-f proposal, recovered from mail sent back in February,
and edited only slightly:
ensure-generic-function <symbol>
&key (generic-function-class
(class-named 'standard-generic-function))
(make-existing-function-default-p nil)
If symbol is fboundp to a generic-function of the same class as
generic-function-class then this function does nothing, and
returns the generic function object.
If symbol is fboundp to a generic-function of some other class, the
generic-function class changing protocol is followed, see chapter 3.
Use (class-named 'generic-function) to prevent changing the class
(is this right? does "of class" here mean typep or eq type-of?)
If symbol not foundp a generic function of generic-function-class is
created and put in symbol's function cell. There was some contention
over whether there should be a create-p argument to control this, or
the caller should do an fboundp test first.
If symbol is fboundp to a function, and make-existing-function-default-p
is not nil, a generic-function is created, put in the function cell, a
default method is added to the generic-function and the symbol's
previous function cell value is used as the function for the default
method.
If symbol is fboundp to a function and make-existing-function-default-p
is nil an error is signalled.
If symbol names a macro or a special form, an error is signalled.
Thus if this does not signal an error, it returns a generic function
object that is now the function definition of the symbol.
<symbol> can also be (setf <symbol>), as proposed later. How does the
caller do an fboundp test of this?
Feel free to change the names of the arguments. Note that this is a
function not a generic-function.
This needs to take additional arguments corresponding to all of the
arguments of defgeneric-options; see make-generic-function on 2-42.
================
CLASS NAMING ISSUE
[I have not yet summarized all the mail on this topic]
================
CLASS REDEFINITION
[I have not yet summarized all the mail on this topic]
================
COMPILER OPTIMIZATION
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.