Argument lists

[Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>]

A single function FUNCTION-PARAMETER-RANGE which returns two values is 
indeed a fine idea. (I don't like -COUNT, though, because it suggests
a single return value.)

Your claim that having this function "adds clutter" is  unsubstantiated
in my mind. The function is simple, well-defined, and useful to a 
definable subset of people. MACSYMA already had such a thing which was
implemented by some of the grungiest system-dependent code you could
imagine.

If you think it duplicates functionality with this other function,
it's probably because your view of functionality is too intimately tied
to data flow. Some functions want part of their contract to be that 
they are fast. If you overgeneralize their return values, as I claim
is happening here, you add "data flow" functionality, but you may end
up forcing some implementations to be slow on an operation that they
didn't need to be slow at, or you may force some implementations to
have to do a radical redesign of their storage technique for arglists
in order to achieve the required speed. I'd just as soon we didn't force
such redesigns for reasons like this where we can so trivially keep
from doing this.

By the way, of the implementations which cache a constant list, I wonder 
how many of them cache a list containing the &AUX spec. I hope we will
make it explicit that &AUX specs should not be visible in the list returned
by ARGLIST. They are not part of the external interface and my experience
is that I always end up writing the same idiom, namely:
 (LET ((AUXL (MEMBER '&AUX ARGL))) (IF AUXL (LDIFF ARGL AUXL) ARGL))
I've done this enough times in destructuring LAMBDA lists myself that
I'd just as soon it were done for me now that we're talking about having
a system supplied tool for extracting arglists. However, I wouldn't want
my FUNCTION-PARAMETER-RANGE function to have to wait for the MEMBER and
LDIFF if I was just going to throw away the result anyway.

Anyway, the real point is that it's not fair for you to make claims about
comparative speeds or even about things probably being fast unless you
have the data to back up such claims. My experience with trying to write
portable CL programs thus far suggests that the only thing you can depend
on are things that are unambiguously specified in CLtL; if something is
not specified, it may vary widely. Speed is certainly no exception.

With regard to your suggestion that the best way to proceed is to hope
that we reach closure on the issue of argument checking, I don't think
that's a good idea. I see no obvious reason for near-term concensus on
that issue and would prefer to assume that FUNCTION-PARAMETER-RANGE
will go in unless I'm pleasantly surprised, rather than vice versa.
Also, resolution of that issue won't be adequate for my purposes unless
number-of-argument checking is required in both interpreted and compiled
code.

By the way, everyone keeps making vague allusions to the new condition
system as if it could somehow solve the issue of argument checking. You
shouldn't hope for magical cures from my camp. The condition system only
says what happens after you signal an error. It doesn't get involved at
all in the decision of when to signal and when not to. The issue of
whether to do number of argument checking (or any other kind of error
checking) is only peripherally related to the issue of how errors which
result from such checks are to be signalled/corrected.