[comp.lang.clos] Beefs

john@LINUS.MITRE.ORG (03/19/91)

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

bane@tove.cs.umd.edu (John R. Bane) (03/20/91)

In article <9103181745.AA18191@mingus.mitre.org> john@LINUS.MITRE.ORG writes:
>
>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.

I think that specializing on &OPTIONAL parameters makes perfect sense, but
mainly in the syntactically godawful case you mention, when the &OPTIONAL
parameters have default values specified.  If there is a specified default,
then as far as the generic function is concerned, the parameter is always
specified, and should be no different from a required parameter for
method lookup.  To really make it make sense, the requirement should be
that all &OPTIONAL parameters have a default expression, and that congruent
parameters have the SAME default expression.

If you want to think about REALLY awful syntax, consider the possibility of
specializing on the svar predicate of an &OPTIONAL parameter:

(DEFMETHOD PRINT-SOMETHING
  ((X MY-THING)
   &OPTIONAL ((STREAM SPECIAL-STREAM)
	      *DEFAULT-STREAM*
	      (STREAM-SUPPLIED (EQL NIL))))

This method obviously ;-) gets run when the STREAM argument is not supplied and
its default value in *DEFAULT-STREAM* is a SPECIAL-STREAM.
--
Internet: bane@tove.umd.edu
UUCP:...uunet!mimsy.umd.edu!bane