Proposals 2, 3, & 4

["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>]

Well, your proposal isn't as bad as I thought in terms of storage
demands.  Thanks for digging up the relevant facts.  We'd probably all
be better off if we used more facts and fewer hunches.

Your proposal may be a good alternative to proposal 4.  It takes a bit
of extra storage to put the & keywords into the list, but probably not
enough to matter.

A question facing both your proposal and proposal 4 is whether we should
save the parameter names as symbols or as strings.  You seem rather
certain that symbols, in the proper package, are necessary.  Do you have
some application in mind where this would matter?  The debugging-type
things I had in mind would get along just fine with strings, and symbols
cost considerably more in storage.

I still think that we should keep FUNCTION-PARAMETERS and maybe
FUNCTION-PARAMETER-RANGE as they are defined in the proposals 2 and 3.
A lot of implementations have this information represented in their
function objects in ways which are carefully optimized for quick access
at function-call time.  To implement proposals 2 and 3, they would just
have to develop ways of accessing this info (plus maybe keeping around a
keyword list for keyword functions).  Accessing this internal info would
in many cases be quicker than extracting the same information from a
list in the format you propose, even if that list is around.  An
implementor might choose to extract this info from a stored arglist
instead, but we shouldn't require that or even encourage it.

-- Scott