[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
- Subject: Argument lists
- From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
- Date: Thu, 03 Jul 1986 00:34:00 -0000
- Cc: common-lisp@SU-AI.ARPA
- In-reply-to: Msg of 1 Jul 1986 19:36-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
- Sender: FAHLMAN@C.CS.CMU.EDU
(In response to the Function-Parameters proposal...)
No. This does not assure adequately fast access to just the max and min
information for use in embedded interpreters. The other info might be
expensive to cons and it may be getting consed for no good reason. I feel
that either there should be two functions, or the function should be given
arguments saying kinds of info you wanted so that no time was wasted in
consing in situations where speed matters. This wouldn't be so essential
if implementations were always required to signal an error in an wrong
number of arguments situation -and- if we had the error system in place.
I expect the latter to happen in the near future, but am not so sure the
former will go through, so I really think fast access to just the numbers
part is important.
I suppose we could add Function-Parameter-Count along with
Function-Parameters. The former would return two values: min args and
max args, with the second value being NIL if there is an &rest or &key.
This is probably better than separate min and max functions, since you
normally want both values and it's faster to get both at once.
This does add clutter, however, so I would prefer not to add this
function unless we really need it. I think it is of very marginal value
for several reasons:
1. Except in the case where the function to be called takes keywords,
the difference in speed between the two calls will be very small
compared to the total cost of a call in an embedded interpreter.
2. I suspect that most implementations will return a pre-stored keyword
list rather than consing up a keyword list on the fly.
3. As you point out, the checking you would do with the
Function-Parameter-Count function is redundant with the checking that
most implementations now do, and that may be required of all
implementations (in the interpreter) if this proposal passes.
Maybe the best way to proceed is to decide now about
Function-Parameters, and for you to raise the issue of
Function-Parameter-Count (or whatever) if you still believe this is
needed after the error system and related issues are firmed up.