Re: Poster boy for optional and keyword args together?

From: Ken Tilton <kennytil...@xxxxxxxxxxxxx>
As someone guessed on the Arc forum, it might be evidence of
evolution, with the keyword args as afterthoughts and importantly a
large installed base of non-keyword usage no one would want to
revisit.

From: Richard M Kreuter <kreu...@xxxxxxxxx>
AFAIR, most cases of &OPTIONAL and &KEY in the same lambda list are
operators where two kinds of argument conventions are both
applicable. For example, input functions take the optional arguments
EOF-ERROR-P, EOF-VALUE, and most functions applicable to strings take
START and END keywords; put these together, and you get most of
READ-FROM-STRING's arglist. Similarly, most character output
operations take an optional output stream, and so WRITE-LINE,
WRITE-STRING take both an optional output stream and START and END
keywords. PARSE-NAMESTRING and WITH-OUTPUT-TO-STRING also have
&OPTIONAL and &KEY in the same lambda list; again, the keyword
arguments follow conventions used elsewhere.

Ah, this is the best explanation I've ever seen of this.
The above paragraph should be in a FAQ.

In a way, this is vaguely similar to Java's interfaces, whereby
some class might satisfy two different interfaces, so that it can
be used in two different kinds of automated contexts, so it has to
provide all the required methods for each of the interfaces even if
they follow somewhat conflicting conventions.

The difference of course is that interfaces are satisfied by OOP
classes, whereby compile-time polymorphism chooses which method to
call (and in many cases the methods have different names anyway so
there's no syntactical conflict to begin with, merely two different
names for [almost] exactly the same D/P task), and each method has
exactly the parameters needed for the corresponding interface,
whereas in these cases of legacy Lisp we have functions not methods
(not even generic functions) so we can't overload the name, we can
only process the lambda list sequentially and stop when there are
no more args, so the programmer must specify the args for
interface#1 (which uses optional arguments) before the args for
interface#2 (which uses keyword arguments).

Whether my analogy with Java interfaces is of any value to most
readers of Richard's explanation, or not, I can't estimate, so I
won't petition for my analogy to include Richard's explanation in
the FAQ. If the basic idea of my addendum would be of value, maybe
KMP can rewrite it to be more newbie-friendly?
.

Relevant Pages