Argument Lists

[Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>]

About 20% of the 10000 symbols in MACSYMA have have no function cell, value,
or properties. The average length of those symbols' names is 7.33.  Some are
probably used as constants within programs, including plist indicators and
catch tags, but I can't believe that all of them are.  I'm more inclined to
believe that most of these are arguments to functions and other variables
(eg, for LET, PROG, etc) which are being retained for debugging. Sometime
when I have more time, maybe I'll try to track down more details.

Symbolics have no real problem with retaining such information on the 3600, 
but I'm not sure what the cost/benefit trade-off is of requiring that this
information be retained in implementations that are tighter on address space.

Also, I should mention that MACSYMA wants to be able to detect the maximum
and minimum number of arguments a function takes, but doesn't really have
a lot of important uses for the whole argument list. The only real argument
I can think of for anyone wanting the actual argument list is as a
user-interface/self-documentation feature, which is an issue that may be best
left up to individual systems. I expect that some people will disagree with
this, though.

Personally, I think that ARGLIST is something of an abstraction violation when
used in some of the ways that I've seen it used, because it exposes the names
the user was using internally and in some cases that may reveal artifacts of
the implementation which ought not be revealed for reasons either of
abstraction or proprietariness or both. Of course, APROPOS is in the same
boat, so I won't suggest there's no precedent for such operations in CL.

There's also a question of how fast ARGLIST wants to be. Some implementations
may have to cons this back up, but some users may be wanting something that's
fast enough to use as a check before actually trying to apply a function in
order to head off wrong-number-of-arguments errors before they happen. The
latter application may not be happy with the speed required to cons an
arglist.  Having more than one function to get these two things would seem
better than having one sledge-hammer that always computes twice as much info
as it needs to and then makes you throw half of that information away.

Storing ARGLIST information out of core would reduce the size requirement, but
would likely make it unacceptably slow for any kind of number-of-args
checking. Also, unlike documentation strings which you can simply drop the
pointers to when you're done using them, symbols that were in the arglist read
from an out-of-core file would continue to be interned unless you explicitly
uninterned them, and you can't do that very safely unless you know for sure
the symbol hadn't been interned prior to the call to ARGLIST.  So over time,
you'd end up accumulating all the information in core in a non-GC-able way.
Maybe that would be OK, but it's worth thinking carefully about to be sure.

Personally, I think something that computes minimum/maximum number of
arguments should be put into the language. I'll defer any recommendation about
something which gets the ARGLIST itself until I've thought harder about the
implications.

If ARGLIST is put in, it should probably be under the name ARGUMENT-LIST.