Pascal J. Bourguignon <pjb@informatimago.com> wrote:
+---------------
| "John Thingstad" <jpthing@online.no> writes:
| > Tim Bradshaw <tfb+google@tfeb.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

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607