[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposals 2, 3, & 4
- To: franz!fizzy!jkf@KIM.BERKELEY.EDU
- Subject: Proposals 2, 3, & 4
- From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
- Date: Tue, 15 Jul 1986 23:15:00 -0000
- Cc: common-lisp@SU-AI.ARPA, fahlman@C.CS.CMU.EDU
- In-reply-to: Msg of 15 Jul 1986 10:56-EDT from franz!fizzy!jkf at kim.berkeley.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
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.