Pascal J. Bourguignon <firstname.lastname@example.org> wrote:
| "John Thingstad" <email@example.com> writes:
| > Tim Bradshaw <firstname.lastname@example.org> wrote::
| >> I think it would be pretty straigntforward to implement a conforming
| >> CL in which symbols were just interned strings. All the other
| >> attributes of symbols can be stored, when needed, in hashtables keyed
| >> on the symbol. Obviously you would pay some performance penalty...
| > But a symbol needs 5 slots of which most are never used.
| Remains the plist, the function and the name. (* 3 4 60000) -> 720,000
| bytes, which is insignificant when you have at least 1 GB of RAM.
| The savings are not worth the complexity. ...
Note that CMUCL actually works a bit like Dan/Tim suggest. In CMUCL,
symbols have slots only for name, package, value, and plist... but
*NOT* for function!! The symbol-function information is stored in
CMUCL's "info" mechanism [accessed either through RAW-DEFINITION
a.k.a. %COERCE-TO-FUNCTION or FDEFINITION, all of which bottom out
in (EXTENSIONS:INFO FUNCTION DEFINITION name)]. This cause no
significant performance problem since the lookup is typically done only
once per occurence [*not* once per call!] -- even for interpreted code,
during minimal compilation.
Rob Warnock <email@example.com>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607