Re: Argument lists: a proposal to shoot at

[Guy Steele <gls@Think.COM>]

    Date: Fri, 27 Jun 86 18:15 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	Date: Fri, 27 Jun 86 14:45 EDT
	From: Guy Steele <gls@Think.COM>

	    Date: 26 Jun 1986 19:17-EDT
	    From: NGALL@G.BBN.COM

	    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.

MIN-and-MAX is somewhat more like the :START/:END convention for subsequences;
required-nad-optional is like start/count.  That is why I chose min and max.

	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
	keywords.

    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 I were doing this on a PDP-10, I might arrange for the keywords to be checked
by stylized code at the start of each function, and would write a little routine
that could grovel through the instructions looking for the keywords.

	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.

Maybe it's not worth eliminating K, I grant.  However, while it may be
reasonable for the author of the code to write (&key), it's not clear
that that information is important to a potential caller who needs to
know what arguments may be passed.  Such a function accepts no keyword
arguments directly, and does not have &allow-other-keys, and so,
operationally speaking, what is the need to know that &key was there?

--Guy