[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>
    To: NGALL@G.BBN.COM, gls@ZARATHUSTRA
    Subject: Re: Argument lists: a proposal to shoot at
    In-Reply-To: <[G.BBN.COM]26-Jun-86 19:17:24.NGALL>
    Message-ID: <860627144507.7.GLS@BOETHIUS.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 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.

Yes. I worried about returning the list of keywords, when all the user
wanted to know was min and max args, for example.  I guess I figured
that pre-stored lists weren't a very high price to pay.  I'm
ambivalent about returning the list vs. returning the the number of
keyword args. and bringing back FUNCTION-KEYWORD-PARAMETERS.
    
    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.
	
Not true. (lambda (&key)...) is legal.
	    --Guy
	-- Nick
    --Guy

	-- Nick