Re: Proposals 2, 3, & 4

[franz!fizzy!jkf@kim.berkeley.edu]

>> 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.

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.

>> 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?  

Since a formal parameter can be a special variable, a string naming
the special variable is ambiguous without the package information.

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.


>> 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).

>> 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.  
 What you're saying is that one implementation's primitive is another
implementation's higher level function.   I agree.  We can't force
everyone to use the same primitive at this stage.  I suggest this
solution:
 1.  The language specification should pick the simplest primitive
     (which I believe is the argument list that I proposed) and write
     the other function-parameter-whatever functions in terms of that
     primitive.  [This adds one more function to the proposed list of
     function parameter functions you proposed]
 2.  implementions are free to write any of the functions in terms of
     any of the other functions, and they are encouraged to make each
     function-parameter-whatever function as cheap to execute as
     possible (e.g. use caching for those functions that must do 
     some work).


- john foderaro
  Franz Inc.