Miscellaneous decisions taken or to be taken

[Gregor.pa@Xerox.COM]

    Date: Thu, 6 Aug 87 22:30 EDT
    From: 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 and on mail received
    in response to the last time I mailed this out (about two weeks ago).   

In the usual way, I have included only parts of your message on which
I am making specific comments.  In several places I have sketched
proposal which were on my to do list.  I am about to go away for a
week and don't have time between now and then to flesh these
proposals out, but I think they are fairly clear from the sketches. 

    

    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.

I have it on my list of things to do to come up with a picture of how
all the standard classes (including standard type classes) are
organized.  I have this on the whiteboard in my office now.  In a
separate message, I will send out the name of a press file which
contains a simple version of such a picture.  If people could FTP
that press file and try printing it, then I could now if its worth
trying to cast the whole picture in that format.


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

Yes, I believe get-setf-generic-function should be a setfable form
with the same provision as Moon mentions.  The way to think of
get-setf-generic-function is just like symbol-function and
symbol-class.  (This may mean that it would be appropriate to rename
it to symbol-setf-generic-function.)  Later in this message, I will
make some other comments which address this issue. 
    

    
    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.

I am not sure what you mean by this.  Surely other non-destructive
operations would be legal as well.  For example, one could implement
some sort of "tracing" :around method by having it get the list of
next methods, and calling each of their functions.  But clearly it
would not be legal to rplaca or rplacd that list. 
    


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

As I said in another message, I don't believe class-name should be
setfable.  symbol-class (nee class-named) should be setfable, it is
possible that it should update class-named as well, the details of
how that updating might work were the subject of my other message.

Even if we decide that class-name should return at most one name, I
think it is clear that a class can have more than one name.  That is,
it is legal to use setf of symbol-class to make the multiple symbols
point to the same class. 
    

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

I have several coments.

First, I believe it is very important that this operation only be a
function of the two lambda lists.

Second, I would rather the rules of this operation be documented.
That is, I would not be as happy if we just provided a function
(make-setf-method-lambda-list) which did the work.  Providing that
function in addition to documenting its behavior might be a good idea
though.

Third, as we agreed, its fine with me to have it be the last required
argument.  But I think we need to be careful how we word this.
Because we have to make it clear what happens in implementations
which have non-standard lambda-list-keywords.



    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.

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.


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

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

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

If this whole mess isn't an argument for a lisp-1 I don't know what
is.  At this point I guess we need:

  symbol-class
  symbol-setf-generic-function
  (both of the above need to be setfable)
  (there needs to be a mechanism for making each unbound)
  (we need to decide how they interact with class-name and
   generic-function-name)

    

    2-16 boa-arglist should support &key and &allow-other-keys.
    2-18 default boa-arglist to be specified

The current initialization proposal doesn't have constructors?

    
    
    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.

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.
    


    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.

I like the prefix option, although I agree that this is a serious
problem.

    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.

What if by the time you actually run the body of the method, the slot
has an accessor.  That is to say, what if you do the following:

(defclass foo () (a b c))

(defmethod bar ((o foo))                ;Put this in a file,
  (with-slots (o) (list a b c)))        ;compile and load it.

(defclass foo ()
    (a b c)
  (:accessor-prefix foo-))

(bar (make-instance 'foo))

Does this signal an error?  It seems to me that the real problem with
this case is the same as the real problem with the above case.  It
all hinges on exactly when macro-expansion time is and that is not
specified. 
    



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

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 volunteered to send some mail about this.

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