Re: string immutability

[Tim Hill <drtimhill@...>]

On Jan 3, 2014, at 1:35 PM, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:

>> I hate to bring this subject back up after it sparked so much debate in the
>> past, but I wonder if this limit could be increased to, say, 64 or 128
>> bytes? In my C libraries' __index and __newindex methods I avoid doing a
>> lot of strcmp()s to compare the key to each valid field name, by storing
>> all valid field names in a table in the registry. String interning means
>> that instead of using strcmp() to check the key I can just use a standard
>> equality test. But that will fail if I have a field with a more than
>> 40-character name (not unimaginable) and Lua doesn't intern the string,
>> meaning the pointer I get as my key isn't the same as the string I stored
>> in the registry.
> 
> For me, a field name with 40 characters is as unimaginable as one
> with 64.  (Once you lose your mind, there is no limit on what you can
> think... :)
> 
> -- Roberto
> 

.. until perhaps you are using UTF-8? I assume the 40 “characters” here means Lua bytes, so if you are using UTF-8 the actual number of encoded code points could be significantly less.

As a side question, I’ve often wondered why the compiler doesn’t pre-hash string literals in Lua source? While it would require changes to the VM, I’d assume you would see some improvement in stuff like global lookups (which tend to be table accesses with literal strings most of the time). Or does the VM pre-intern all the literals in the compiled Lua chunk when it’s loaded?

—Tim