[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Argument lists: a proposal to shoot at
- To: Guy Steele <gls@Think.COM>, common-lisp@SU-AI.ARPA
- Subject: Argument lists: a proposal to shoot at
- From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
- Date: Fri, 27 Jun 86 16:10 EDT
- In-reply-to: <860626123445.9.GLS@BOETHIUS.THINK.COM>
Date: Thu, 26 Jun 86 12:34 EDT
From: Guy Steele <gls@Think.COM>
In the following function descriptions, assume that the argument
function has Q required parameters and P &optional parameters, and that
R, K, or A is true iff the function has respectively a &rest, &key, or
&allow-other-keys lambda-keyword.
...
Point of design philosophy: &aux "parameters" aren't anybody's business
at this level of abstraction. I don't deny that for the sake of
debuggers this information, and such other information as the names of
parameters, may be desired.
Other ideas for consideration:
I think the max number of parameters before the &rest is useful.
Why not one function that returns just about everything as multiple
values? Something like
(values min-required-args
max-spead-args
takes-rest-arg-p
takes-keywords-p
allows-other-keywords-p)
Consider a system that allows the programmer to override the argument
list with a declaration, such as
(defun foo (a b &rest c)
(declare (arglist symbol indicator &key package value &allow-other-keys))
...)
Do these functions return what the function really wants or what the
user says it wants?
Consider the case
(defun make-raster-array (width height &rest make-array-keywords
&key &allow-other-keys)
(apply #'make-array (list height width make-array-keywords)))
Here, there are keywords accepted, but it isn't really clear which ones,
since this is an abstraction on top of make-array. [I don't have a good
answer to this one.]