Various Topics Discussed Last Week

[kempf%hplabsz@hplabs.HP.COM]

After an unsuccessful search for desert bighorn sheep at 9,000 feet in
the eastern Nevada mountains, here are some comments on the week's mail:

1) On SETF:

I agree with Gregor that we should drop SETF methods from the language
for now. I don't think requiring the user to write a DEFSETF is excessive,
since SETF is currently just syntatic sugar anyway. I think I understand
Patrick's concerns about not being able to use the short form, but am
concerned that, if we don't drop DEFMETHOD-SETF and kin we may be wiring 
short term solutions into the spec which would preclude making an underlying 
fix, as Masinter and Gregor have suggested. I agree that we should 
propose a fix. I like Moon's way of defining a SETF function, and the 
idea of function specs in general. We seem to be continually stumbling 
on where they can be useful (DOCUMENTATION, TRACE, SETF functions, etc.). 
I think the addition of methods and generic functions to Common Lisp 
has magnified this lack in the underlying language.

For purposes of finalizing the spec for the November meeting, I think we 
should drop reference to SETF methods. I'd like to co-ordinate the TRACE
proposal to the cleanup committee along with anything Gregor might
propose involving function specs.

2) On blocks in methods:

I agree that Alternative 1 would be best. Users who want something
different can either use a :AROUND method, as Moon suggested, or 
program their own generic function dispatching function, using
the metaobject protocol.

2) On dynamic v.s. indefinite extent for CALL-NEXT-METHOD:

Dynamic it is.

3) On the object creation proposal:

Here are some specific comments on Moon's basenote:

>                                                             The form
>is evaluated in the lexical environment in which the DEFCLASS form was
>evaluated.

When reading this, it sounded like the form would, in addition, be
evaluated when the DEFCLASS form was. From reading the rest of the
basenote, I see that it is not, but some kind of forward reference
here would prepare the reader. Also, from the rest of the note, it seems
as if it is implementation dependent as to when the initforms are
evaluated. This is fine, but should be in the concepts section as
well, I think, with a warning that users need therefore to be especially
concerned about initforms which depend on side effects, if they want
to achieve portability.

> When more than one class in the CPL specifies a default value
>form for a given initarg, only the form specified by the earliest such class in
                                                          ^^^^^^^^
>the CPL is used.

Suggest use of "most specific", since "earliest" could be interpreted
either way.

>The primary method for INITIALIZE-INSTANCE is system-supplied and takes care
>of the slot-filling initargs.  For each slot (whether local or shared):
>
>  - if an initarg was specified or defaulted that fills that slot, its
>    value is stored into the slot.
>
>  - otherwise, if the slot is uninitialized and it has an initform, the
>    initform is evaluated and the result is stored into the slot.
>
>  - the duplicate-resolution rules mentioned earlier are obeyed.

Something needs to be said here about the case where a user writes
a :BEFORE method and SETF's the slot there. From the rest of the text,
it sounds as if INITIALIZE-INSTANCE is permitted to clobber that slot.
This makes :BEFORE methods on INITIALIZE-INSTANCE less then useful
for slot initialization. The result requires either that INITIALIZE-INSTANCE 
be singled out in a particular way to prohibit :BEFORE methods, or allows
the system to arbitrarily clobber something the programmer has done.

One way out of this dilemma is to simply have the :BEFORE method and the
:AROUND method for INITIALIZE-INSTANCE be reserved for the system.
Similarly for the :AFTER and :AROUND methods of ALLOCATE-INSTANCE. 
This would leave no places where user defined hooks could be inserted before the
INITIALIZE-INSTANCE primary is run. Users redefine these qualified methods
at their own peril, as is the case with redefining any system defined
method (or function for that matter).

>Do you think it would be worth trying a version of the writeup that uses
>CLtL's terminology, with a simple admonition that a "keyword name" is not
>necessarily a keyword symbol?

Yes, this would be a good idea. I think a case can be made for a semantic
distinction between keyword symbols and keyword arguments. The term
keyword argument is used in Smalltalk as well, where the concept of
keyword symbols does not occur.

4) On method combination types:

> CALL-NEXT-METHOD is supported in :AROUND methods only.

     ....

>An error is signaled if CALL-NEXT-METHOD is used in a primary method. 

In primaries as well???? If so, then we're talking about a major change,
because 87-002 allows it in primaries. Or perhaps this is only for the new 
method combination types? If so, then I'd be interested in a reason
for prohibiting method combination in primaries, since it introduces
a major incompatibility between different types of method combination.

5) On :INSTANCE v.s. local:

Either way is OK.

6) On DEFMETHOD syntax changes:

Good.

7) On NEXT-METHODS:

The primary reason is for being able to tell if calling CALL-NEXT-METHOD
would signal an error. I understand Masinter's concern, and wonder if
perhaps it might not be better to handle this with Ken Pitman's error
proposal. Other than finding out whether a call to CALL-NEXT-METHOD is
valid, there isn't much use for the list of next methods, as Masinter
has pointed out.

8) On changing the names of built-in classes:

Good.

9) On SLOT-UNBOUND:

Good.

10) On NO-APPLICABLE-METHOD:

>( no-applicable-method generic-function first-argument &rest
>all-arguments)

I thought we had agreed to get rid of the first argument kludge.
Otherwise, this is the only place in the entire spec where
we're making a distinction between multiple dispatch object
oriented programming and classical object oriented programming.
The user has to go through some additional grief if all the
arguments are passed as an &REST parameter in order to get
forwarding, but I think that forwarding should best be left
to metaobject programmers anyway, since it is, as yet, experimental
(neither PCL nor New Flavors have it). Someone could write a
forwarding metaobject method as:

  (defmethod no-applicable-method ( (gf forwarding-generic-function)
                                    &rest all-arguments
			          )
     (apply #'forward-method all-arguments)
  )

A user can do something similar with the default method, with
somewhat hairier code.

I think the primary reason people using the default CLOS language
(as opposed to the metaobject protocol) would want all the arguments
anyway is to print a more informative error message.


There are a couple of additional issues which will require specific
longer responses. I'll mail these out today.

		jak