Proposals 2, 3, & 4

[Rob MacLachlan <RAM@C.CS.CMU.EDU>]

    Date: Tuesday, 15 July 1986  10:56-EDT
    From: franz!fizzy!jkf at kim.berkeley.edu
    To:   Scott E. Fahlman <ucbkim!C.CS.CMU.EDU!Fahlman at kim.berkeley.edu>
    cc:   common-lisp at su-ai.arpa
    Re:   Proposals 2, 3, & 4 

    Actually storing the & keywords in the list saves space overall since
    it then doesn't require you to have fixed, normally empty, slots to
    hold rest, optional and key symbols.

The point is that nearly all implementations will already have the arg
count information stored in some other way so that their call
mechanisms can work.  It is desirable to separate the mandatory
semantics of the call interface from the informational content of
parameter names.

    For debugging interpreted code you would  like the  symbol for each of
    the formal parameters since that would permit the debugger to poke through
    the lexical environment an locate the current value of that argument.
    [You can imagine cases where using a string for the name would be
    ambiguous.]  If symbols are to be used for interpreted code, then
    using strings for compiled code would be a pain.

Debuggers are blatently non-portable anyway.  I question that there is
any use for paramater names in portable code other than simple
display.  A debugger is certainly not an example of such a use.

    >> The debugging-type
    >> things I had in mind would get along just fine with strings, and symbols
    >> cost considerably more in storage.

    Most people tend to use the name parameter names over and over again.
    Recall that for the 627 functions in our lisp package, the total
    length of the parameter description lists is 1510.  There are only 248
    unique symbols in that list of 1510.    I think that in this case
    saving the parameters as symbols saves a significant amount of space
    over saving the parameters as strings (unless you simulate a package
    by creating a hash table of parameter name strings, in which case
    it is hard to say which is more space efficient, it depends on how many
    of those 248 symbols would have existed anyway).

This argument is plausible, but incorrect.  Changing to a string
representation in Spice Lisp significantly reduced storage.  This is
partly due to the use of a single string for the entire argument list.
Some sharing of strings also exists, since our fasl dumper makes equal
strings EQ, thus making identical strings in the same file EQ.  It is
also significant that boxed symbol, package and list storage was
replaced with unboxed string storage.  This change eliminated >1000
(10%) of the symbols in our core image.

I think that using the arglist to indicate argument info is silly
unless the paramater names are required to be right, and that it is
unreasonable to require the names to be stored.  The semantics of the
language require the storage of the information returned by
FUNCTION-PARAMETERS, so every implementation must have some way to
access this information.

  Rob