[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Argument lists: a proposal to shoot at
Date: Fri, 27 Jun 86 14:45 EDT
From: Guy Steele <gls@Think.COM>
Date: 26 Jun 1986 19:17-EDT
How about keeping the number of functions down and eliminating the
'encoding' in MAX-ARGS, and using correct terminology with the
following one-function alternative to FUNCTION-MIN-ARGS, -MAX-ARGS,
-HAS-KEYWORD-PARAMETERS, and -KEYWORD-PARAMETERS. I think
FUNCTION-KEYWORD-PARAMETER-P addresses an idiom common enough to
warrant its own function.
FUNCTION-PARAMETERS function [Function]
Returns Q, P, R, K, a list of keywords explicitly accepted by the
function (order undefined), and A. Note that if K is false, the list
is necessarily empty.
I like one function to return all the information better than a bunch of
separate functions. As for whether it's better to return min-and-max or
required-and-optional, in all these years I've never made up my mind on
that point. I do think it's a good idea for the presence of &rest or &key
not to throw away the information about how many positional parameters
there are, even if some of the proposed uses for that information are
bad ideas. In the min-and-max model, max could be the maximum number
of positional parameters, thus you have to look at (OR R K) to know
whether this is actually the maximum you are permitted to pass.
I have to admit (blush) that another design criterion I employed implicitly
was that it should be possible to acquire most of the information without
either consing on the fly or requiring an explicit pre-stored list of the
I don't understand how the information would be accessible at all if
there was not a pre-stored list. Perhaps you have some clever
implementation in mind? If this is really important, we could have both
FUNCTION-PARAMETERS and FUNCTION-KEYWORD-PARAMETER-P, with some way to
tell FUNCTION-PARAMETERS not to bother creating the list. But I like it
better with just one function. Anyway I know how to not be bothered
by consing on the fly.
In your proposal for FUNCTION-PARAMETERS, I observe that returning K
is redundant: K is true iff [(the keyword list is not empty) or A].
That's not to say that returning K separately isn't a good idea.
(defun foo (&key) ...) has some semantic meaning, namely that if this
function is ever extended it's going to take keyword parameters. If you
don't think this is a realistic example, see CLtL page 427.
I don't think clever elimination of the K return value is advisable.