Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!tut.cis.ohio-state.edu!unreplyable!garbage
From: john@LINUS.MITRE.ORG
Newsgroups: comp.lang.clos
Subject: Specializing on &OPTIONAL parameters (was moooo!)
Message-ID: <9103201709.AA20839@mingus.mitre.org>
Date: 20 Mar 91 17:09:04 GMT
Sender: welch@tut.cis.ohio-state.edu
Distribution: inet
Organization: CommonLoops
Lines: 58

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 Burger