Re: Arg count checking

[masinter.pa@XEROX.ARPA]

The only places I've seen extra args used in situations where it isn't
(clearly) a bug is in code that is dealing with two different
implementations.

Implementation A has a function FOO with args A B and an optional C.

Implementation B has a function FOO with args A B. No optional.

You can then write a client that will work with both implementations, as
long as it knows that some implementations may ignore the last argument.
(Most of the cases I've seen have been ones where its been a "flag",
e.g. implementation A has a "slow" and a "fast" case, and you can say
(FOO 1 2 T) and it means do (FOO 1 2) and, if you care, do it fast
rather than slow..., although there have been other uses.)

I can think of about a half-dozen cases of this, off hand; e.g., the
"standard system" has a vanilla WHEREIS, but there's a super-WHEREIS
that takes lots of args, and it redefines WHEREIS to have lots of
optionals.  

The odd thing is that I can't think of a really clean way of doing
this-- having variant argument lists in different implementations -- I
suppose you'd have to write a &REST in every implementation that didn't
have the args.

Another place this arises are in mapping functions which take functional
arguments; they apply the functional arg; sometimes they pass extra
arguments which of course the functional is free to ignore. 

All of these are instances where the CALLER knows the args are optional.

I can imagine (not very seriously) a separate syntax for that, e.g., put
the &OPTIONAL on the caller rather than the callee:

(FOO 1 2 &OPTIONAL T) which says to call FOO with 2 arguments, and throw
away the third if FOO only takes two arguments, but otherwise pass it
all three.

Can this be different than multiple-value-return where the caller is
expecting fewer values than the callee returns?