Miscellaneous decisions taken or to be taken

[David A. Moon <Moon@STONY-BROOK.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.  The rest of this
message is it.


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.

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?

!
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, I think
  because existing interfaces might not be transformable.

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

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.

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.

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.

  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.
  We need to decide whether class-name of an anonymous class is nil.

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).

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
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 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.]

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.

  Agreed.

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.
  Gregor will propose the details.
!
This page is a list I made in March, keyed by page numbers in the
document, that hasn't been shown to anyone yet.  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.

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.  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?

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.

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.

  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

  July: Agreed

2-45 make-method should be deleted, redocumented as a class
that can be given to make-instance

  July: Agreed

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.

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
next meeting.

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.

2-7, 2-46 [The proposed extension to call-next-method has been accepted.]

2-41, 2-48 [Perhaps we can adopt the condition signalling system now.]
!
Other issues:

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

Ida: make-specializable seems to be missing

  Gregor's proposal for get-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.

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?

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.

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?

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.

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.

  Gergor volunteered to send some mail about this.

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

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.