🚀 go-pugleaf

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