Remarks

[Dick Gabriel <RPG@SAIL.Stanford.EDU>]

Here are some remarks on the topics discussed recently. By the way,
there is a new CONCEP.TEX and CONCEP.DVI on SAIL.

These remarks treat the issues in reverse order to how they were
sent to the list:

    I think defgeneric should handle its specially-defined methods
    in exactly the same way that defclass handles its.

I'm not sure what the specially-defined methods might be for a defgeneric.
My reading of the specification states that if some method descriptions
are supplied some methods are defined, but none of those are specially
defined in the manner that they are using defclass - in the defclass case
I suppose the specialness is tied up with the fact that they are
implicitly defined, though at the behest of the :reader, :writer, or
:accessor options. I notice no other methods mentioned.

The model currently stated is clear - defgeneric is semantically equivalent
to an ensure-generic-function and a series of defmethod's. I see no obvious
parallel with defclass. With defclass, the ``specially-defined'' methods are
so defined according to a strong convention that we have imposed - we would
all be surprised to see people write simple defclass forms and then a
series of defmethod's to build up the readers and writers. But the
method-defining parts of defgeneric are form completeness only - we do
not advocate that people write method definitions within defgeneric forms.

If people do not like the fact that re-loading defgeneric forms doesn't
do what they want, then they can re-write them as simpler defgeneric's
and defmethod's, and they will be obeying classic object-oriented style
all the more if they do. 

So I am against treating these methods in a manner analogous to
those defined by defclass.

On ADD-METHOD:

	   Since there are ways of getting methods, and moving methods is
	   a reasonable thing to do, I think it is still reasonable to
	   have add-method in chapter 2.

I know one can get methods, but I thought it was not possible to take a
method from one generic function and move it to another - that all one
could do is grab a method, grab its method function, make up a method
object from that, and then put that on a generic function. The step of
making the method object is achieved by make-instance of standard-method,
which is in chapter 3. Therefore, I believe it belongs in chapter 3.

	   Didn't we agree that in the long run, there will only be two
	   chapters - with extensions to chapters 1 and 2.

I think we agreed that in the long run this is desireable. We are currently
not trying to accomplish this merger, and I think it is reasonable to
to alter that to trying to not accomplish the merger. The point of this
is to make sure that the X3J13 troops can see what they get and don't get
if they think they don't like meta-object stuff. I'm sure that they
will desire inclusion of chapter 3, and at that point someone can
make the enormous effort to merge them. I think that it would be
easier for that person if they have a cleanly separated base level
and meta level to start with, especially if that is so easy to
accomplish right now. Remember, I want to go to the next meeting
with a chapter 1-2 package that stands alone and a chapter 3 package
that can be easily added.

I think that having such a separation can help our strategy at X3J13,
which would be to state that here is chapters 1 and 2 neatly wrapped
up as we promised, and all that needs to be really discussed is chapter
3.  We can avoid unnecessary yapping by the hangers on that this
or that detail in chapter 1-2 is unpalatable, and we can have that
important chapter 3 discussion in which we sell it to them.