Re: Unique string storage

Donald Beaudry (don@vicorp.com)
Tue, 5 Apr 94 13:33:15 EDT

>>>>> On Tue, 5 Apr 94 10:40:14 MDT, lutz@KaPRE.COM (Mark Lutz) said:

> But wouldn't extending strings be more simple, semantically, than
> adding yet another data type?

Simpler yes, better no. I think a few good points were already made
about why it would be a bad idea to uniqify all strings.

> If you made class attribute access fast enough, I'd be satisfied
> with implementing symbols as a Python-coded class.

I agree. And, I think the way to make attribute access fast enough is
to use symbols internally. I have not tried profiling Python yet, but
I would bet that strcmp() is in the top 10%. An internal symbol
management system could be used to eliminate many of these calls. The
compiler and code generator would be able to generate more efficient
code faster. Since much of the uniqueification could be done when
compiling python code I see very few cases where a runtime penalty
would be imposed. For example, in 'obj.attr' attr could interned
during compilation.

Now, assuming that Python has an internal mechanism for symbol
management, why not export that functionality to the user. I would
suggest adding a new lexical convention for symbol literals, like
$symbol for example, and a couple of functions for converting symbols
to strings and strings to symbols.

I think that lisp has shown us how useful this concept really is, but
the real benefit, IMHO, would be the speed increase in the python
implementation.

--Don

Speaking of lisp, is anyone interested in a cons cell object?