john@LINUS.MITRE.ORG (03/21/91)
bane@tove.cs.umd.edu (John R. Bane) writes:
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.
First of all, &OPTIONAL parameters always have a default default :-)
value, NIL. So there's no such thing as an &OPTIONAL parameter with
no default value. Second, your comment makes it sound like failing to
specify a value for an &OPTIONAL parameter when calling a function is
the same as specifying the default value. I don't agree. The default
value is just a convenient way to specify what to do when the caller
doesn't specify a value. If non-specification and specifying the
default were the same thing, why does CL provide the ability to
distinguish between them? (I'm referring to the SVAR predicate for
&OPTIONALs, which John mentions later.)
Consider the following method:
(DEFMETHOD ADD-CONDIMENT ((FOOD HAMBURGER)
;; Condiment defaults to ketchup
&OPTIONAL (CONDIMENT :KETCHUP))
...)
If someone uses the following call:
(ADD-CONDIMENT *BIG-MAC*)
they are NOT specifying the CONDIMENT parameter, and method lookup
should NOT depend on what they've failed to specify.
I definitely don't agree that congruent &OPTIONAL parameters in
different methods should have the SAME default expression. The point
of a method is to specify the behavior of a function when some of the
function's arguments are of particular types. Given that, I think it
makes perfect sense for the method to also specify what to do when
certain parameters are unspecified. Consider the previous
ADD-CONDIMENT method along with the following:
(DEFMETHOD ADD-CONDIMENT ((FOOD TUNA-FISH-SANDWICH)
&OPTIONAL (CONDIMENT :MAYONNAISE))
...)
The default condiment to use depends on the food.
In fact, if all default values for a particular &OPTIONAL parameter
were the same in all methods, and you could specialize on that
parameter, how much good would it do you? All of your specializations
would have to include the default value, so it doesn't sound very
useful.
John Burgerbane@tove.cs.umd.edu (John R. Bane) (03/21/91)
In article <9103201709.AA20839@mingus.mitre.org> john@LINUS.MITRE.ORG writes: > >First of all, &OPTIONAL parameters always have a default default :-) >value, NIL. Right. My language-lawyer skill has slipped, missing that one. > Second, your comment makes it sound like failing to >specify a value for an &OPTIONAL parameter when calling a function is >the same as specifying the default value. I don't agree. > > [ Nice example involving sandwiches and default condiments ] > >In fact, if all default values for a particular &OPTIONAL parameter >were the same in all methods, and you could specialize on that >parameter, how much good would it do you? All of your specializations >would have to include the default value, so it doesn't sound very >useful. > Having default values that vary based on the type of the required values is potentially useful, but then you can't discriminate on the defaults at all; you have to pick one method and evaluate its default expression without knowing whether the type will match. Discriminating on default values IS useful, though, when the default value is an expression; defaulting to a rebindable variable is the simplest example of this. Isn't one of the annoyances of making CL streams CLOS objects the fact that most of the top-level I/O functions take their streams as &OPTIONAL parameters or keyword parameters, so they can't be methods that specialize on the stream? Sure, you can get around it by defining them all in terms of underlying methods, but then the handling of keywords gets ugly. Requiring methods to have matching defaults is the simplest restriction I can think of that makes specializing on defaults meaningful and useful; unfortunately it cuts out your example, and God Forbid CLOS cut out anything potentially useful, even if not doing so makes the common case ugly. -- Internet: bane@tove.umd.edu UUCP:...uunet!mimsy.umd.edu!bane
dsr@mir.mitre.org (Douglas S. Rand) (03/21/91)
.... Lots of discussion about the topic But, there is nothing which prevents a programmer from creating a wrapper function with optional parameters which calls the generic function. So: (defun wrapper-function (x y &optional (a (sexp))) (function x y a)) (defmethod function ((x sp1) (y sp2) (a sp3)) body) Why doesn't this totally satisfy the question? Please don't tell me it's so people can specialized builtin functions to CL because the committee has already disallowed this one (unless it's changed while I wasn't looking :) ). -- Douglas S. Rand Internet: <dsrand@mitre.org> Snail: MITRE, Burlington Road, Bedford, MA Disclaimer: MITRE might agree with me - then again... Amateur Radio: KC1KJ