[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Argument Lists
- To: Dave.Touretzky@A.CS.CMU.EDU
- Subject: Re: Argument Lists
- From: firstname.lastname@example.org "Mike Beckerle"
- Date: Mon, 23 Jun 86 11:12 EST
- Cc: common-lisp@SU-AI.ARPA
- Sender: mike@a
Date: 22 Jun 86 22:01 EDT
One compromise might be to include ARGUMENT-LIST in the language but specify
that the argument lists of compiled functions may not be accessible. So
people writing programmer's aids for handling interpreted code (as I have
done) can still get the info they want without being forced to rip apart
closure objects or SI:DIGESTED-LAMBDA forms. There should probably be a
compiler declaration to force argument list info to be preserved (or thrown
away), for applications like Brian Milnes' where you need the info in
compiled code. The default fate of argument lists in compiled functions can
be left up to the implementation.
We should not compromise on number of args info though; that should be
available for all functions, compiled or not.
By the way, what will the convention be for indicating that a function has
an &rest arg? I guess one could just return the value of call-arguments-limit.
Asking for the number of args at run time, or whether the function
takes an &rest arg is asking for type information about functions.
Someone else might want to know the number of results, or possibly
the types of the arguments, etc. Common Lisp already has typing
features which address these kinds of problems. For example, the
type-of operation can be used for this purpose, i.e., why not do:
(type-of (symbol-function 'foo))
and have it return the function type specifier, which might be:
(function (t t &optional t &rest list) t)
This could then be parsed to determine the number of args info, or
any other available type info about the function. Requiring that
number-of-args be available is tantamount to requiring type-of to
always be able to return a function signature containing at least the
right number of arguments. In other words, it is equivalent to
asking that the type-of function be required to return alot more
information than CLtL currently specifies.
I think type-of should be required to return a function type
specifier for function objects, and that the lambda list in the
specifier must reflect the arity, as well as use of &key, &optional,
&rest, etc. Argument-list should then be defined in terms of type-of.
Note that since type-of returns a function type specifier instead
of an actual lambda-list, there is no loss of abstraction here, i.e.,
only the type of each argument is shown, not the name of it.
This may be a bug, since at the user-interface level, most use
of arglist is to look at the names of the args to determine
their order, not their type. Extending the function spec syntax
is one way to fix this, i.e.,
(function ((the integer x) &optional ((the list foo) nil)) t)
Also, number-of-args is quite ambiguous in the presence of &key,
&optional, and &rest args, and would be especially troublesome
with respect to macros, where nested lambda lists can be used.
Gold Hill Computers