🚀 go-pugleaf

andreasg@sigi.Colorado.EDU (Andreas Girgensohn) writes:

> I would prefer that different methods of the same generic functions
> could have different numbers of required parameters.  The selection
> of the applicable method(s) would depend on the number of parameter
> in addition to the types of the parameters.  I would also like to be
> able to specialize optional parameters.

I don't think it makes sense to specialize on &OPTIONAL parameters.
For instance, think about:

  (DEFMETHOD PRINT-SOMETHING ((X MY-THING) &OPTIONAL (STREAM SPECIAL-STREAM))
    (PRINT-MY-THING-INTERNAL X STREAM))

Here, (STREAM SPECIAL-STREAM) is meant to indicate the specialization
of the optional argument STREAM, not its default value.  Let's not
even bother discussing the necessary (but horrible!) additions to the
syntax that would distinguish between specializations and default
values.

Is this method applicable if I do the following?

  (PRINT-SOMETHING (MAKE-MY-THING))

No, one might say, because I'm implicitly passing in the value NIL for
the STREAM parameter.  What if the default value for STREAM in that
method was (MAKE-SPECIAL-STREAM)?  Well, it depends on whether default
values are assigned before or after method applicability is
determined.  I think this could be argued either way, although I'd
lean towards after, in which case the method would still not be
applicable.

This all sounds rather dubious, however.  Then, consider the question
of what the lambda list for a generic function looks like if its
methods don't have congruent lambda lists, e.g.

  (DEFMETHOD PRINT-SOMETHING ((X FOO) &OPTIONAL STREAM)
    ...)

  (DEFMETHOD PRINT-SOMETHING ((X BAR) STREAM)
    ...)

What is the lambda list for the function PRINT-SOMETHING?  I don't
know, but this doesn't make me believe that non-congruency is a good
idea.  Everyone probably knows what "the right thing" is.  Trouble is,
none of them are the same "right thing".