Common LOOPS

[Guy Steele <gls@THINK-AQUINAS.ARPA>]

I am delighted to learn that there will be a meeting during IJCAI-85 to discuss
object-oriented programming in Common Lisp.  I am not planning to attend IJCAI,
but I trust that those who do attend will have a productive meeting.

Yesterday I received in the mail a draft specification of Common LOOPS, by
Bobrow, Kahn, Kiczales, Masinter, Stefik, and Zdybel.  This is, as far as I
know, the first major polished proposal to result from any of the subcommittees
formed last year at Monterey.  We should all be grateful to these authors for
the work they have obviously put into preparing this proposal, including doing
an implementation up front and comparing it to other object-oriented Lisp
programming systems.  This is not to say that I endorse every detail of the
entire proposal in its current drafty state (for I am not sure I yet understand
all of the implications), but it is very encouraging that there will be a
concrete, demonstrably implementable proposal to discuss at the IJCAI meeting.


I have a couple of specific technical comments that you may want to take into
account:

(1) Section I.G mentions the waffling of the Common Lisp manual on the question
of exactly what TYPE-OF returns.  The motivation for the waffling was primarily
to avoid the question of whether TYPE-OF should return implementation-dependent
or extremely specialized subtypes.  Should (TYPE-OF 3) be INTEGER?  FIXNUM?
(INTEGER 3 3)?  (INTEGER 0 NIL)?  I couldn't get a consensus of what the
correct thing to do was, so I took the easy way out there by being
noncommittal.  Perhaps this was not a good thing for me to have done.


(2) Section II.I presents an example that purports to be an anomalous case, but
I find it quite clear-cut.  The second method for FOO clearly cannot accept
three arguments under any circumstances, and therefore is not eligible to
handle a three-argument call.

I think that the semantics of &optional and &rest parameters are easily dealt
with by viewing them as an abbreviation mechanism for multiple methods.

	(defmethod foo (a b &optional (c x) (d y)) body)

is simply an abbreviation for

	(defmethod foo (a b) (let ((c x) (d y)) body))
	(defmethod foo (a b c) (let ((d y)) body))
	(defmethod foo (a b c d) body)

Similarly,

	(defmethod foo (x &rest y) body)

is simply an abbreviation for

	(defmethod foo (x) (let ((y (list))) body))
	(defmethod foo (x y1) (let ((y (list y1))) body))
	(defmethod foo (x y1 y2) (let ((y (list y1 y2))) body))
	(defmethod foo (x y1 y2 y3) (let ((y (list y1 y2 y3))) body))
	...

I would suggest that a type specifier attached to a &rest parameter
be construed as applying to EACH of the arguments encompassed by that
parameter.

Keyword parameters can be handled in much the same manner, although
the question of which is to the left of another in multiple definitions
(for purposes of establishing method precedence) is problematical.

--Guy