[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposals 2, 3, & 4
- To: "Scott E. Fahlman" <ucbkim!C.CS.CMU.EDU!Fahlman>
- Subject: Re: Proposals 2, 3, & 4
- From: firstname.lastname@example.org
- Date: Mon, 14 Jul 86 15:57:15 PDT
- Cc: email@example.com
- In-reply-to: Your message of Mon, 14 Jul 86 14:18:00 EDT. <FAHLMAN.12222664034.BABYL@C.CS.CMU.EDU>
>> The primitive function would return a sequence something like this
>> (a b c &optional d e &rest r &key x y &allow-other-keys)
>> or a keyword signifying that it doesn't have the information.
>> I don't like this approach at all. It seems to make more work for
>> everyone and to require that all this information be carried around in
>> an inefficient and hard-to-parse form.
Inefficient? Actually this holds the minimum amount of information
necessary to return the values in proposals 2 through 4 (if you must
return symbols, and I think you must). I just did a check of the
lisp package functions. The info is:
max length of above type of list: 13
total length of all lists: 1510
average size of list 2.4
functions with optional 105
functions with rest 69
functions with key 94
I've used a list to hold the information. A vector may
be more space efficient, it depends on the overhead per vector since the
average list size is small.
Notice that there are few functions with rest and key arguments. Thus if
you use a fixed size structure for holding the key and rest
information, you will be wasting those slots most of the time.
As for hard to parse, it is actually quite easy to parse, and as I
said before the source code for functions to do the parsing and to
return the information requested by proposals 2,3 and 4 should be part
of the specification.
- john foderaro