[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Argument-lists and friends
- To: common-lisp@SU-AI.ARPA
- Subject: Argument-lists and friends
- From: MURRAY%cs.umass.edu@CSNET-RELAY.ARPA
- Date: Mon, 23 Jun 86 14:59 EST
I asked for this function a while ago. I feel handicapped without
being able to quickly see the arglist to a function.
Without this function, we now put the arglist in the docstring,
which is probably a good idea anyway. But that does require you
to have a docstring for the function. That may be fine for
user-interface, but the more important problem is for it to
be program accessable.
I think it is important that a common-lisp interpretor can be written
in common-lisp. To do this, there are three things that my Visual Stepper
has to hack in an implemention dependant way:
1. What the argument list is to a function. For this I need
the entire arglist, with &AUX variables and init forms as well.
If a system provides anything less, it is useless except to
find the minimum and max arg count.
2. The body to the function.
3. Whether a binding should be special.
For uncompiled objects, the first two things should be accessable
without any overhead. For compiled objects, it may be asking to much
for this information. In this case, you should
at least be able to get the min and max number of args, to do
code analysis. I think the following proposed functions should be
optional in common-lisp, but strongly encouraged to be supported:
FUNCTION-ARGLIST that takes a symbol and returns the DEFUN supplied
argument-list, and a second value of T, if the first value is
meaningful. If the second value is NIL, then the first value is meaningless.
FUNCTION-BODY takes a symbol and returns the body of the defun
(with the BLOCK around it), and again a second value indicating the
validity of the first one.
FUNCTION-ARGCOUNT takes a symbol and returns two values, minimum
argcount and max argcount, or NIL for both indicating invalidity.
Each of this functions should signal an error if the symbol is not
In the case of a macros, we could have analogous MACRO-xx functions,
so one could interpret macro expansions. Alternatively, the above
functions could take any function-object as well as a symbol, so
*macroexpand-hook* could be used to interpret macro expansions, giving
the function-object argument to the above functions.
Just to complete my need, I propose SPECIAL-VARIABLE-P to return
T, if a symbol is globally special.