Re: Lua strings as "atoms"???

[Mike Pall <mikelu-0505@...>]

Hi,

Rici Lake wrote:
> In any event, I can imagine implementations of Lua which would have 
> precisely the property suggested by the refman with respect to strings. 
> For example, a short string (for some definition of short) might be 
> stored directly in the stack slot. With a bit of careful rearrangement, 
> you could fit 11-15 characters in a stack slot (depending on what the 
> minimum alignment of a pointer is on your 64-bit architecture, if any). 
> That might significantly reduce contention on the string table, 
> particularly as the aforementioned 64 bit architecture is likely to be 
> able to do a 16-byte aligned comparison fairly rapidly. In fact, I've 
> been tempted to try that.

You'd need a new internal type value for that. And then special
case all equality comparisons. And provide for some way to migrate
a stack string to a (unique) heap string (and back?). And I bet there
are a few more pitfalls.

I can think of only one use case: processing lots of short strings
in sequence (passing them back and forth to string.* functions).
But as soon as you store a string in a table or index a table with it,
you pay the heap allocation overhead, anyway.


Mutable strings (plain buffers or buffer lists/trees) may be a better
solution. However this must be a core data type: you need a C API
to access the raw buffer and not just a __tostring metamethod.
Otherwise you loose all advantages since every C function needs to
convert them to/from immutable strings (which is exactly what we
want to avoid). And indexing tables is tricky, too.

Anyway, it would be a pretty unorthogonal extension. And with proper
design of your I/O functions you can avoid mutable strings alltogether.
Just allow passing multiple args and (nested) tables of strings.
The speed advantage of a hand tuned buffer list/tree implementation
against string lists/trees done with plain Lua tables (the array part)
is not that big. And it's likely to be a net loss when you consider
that you can use VM ops to manipulate tables, but always need to call
C functions to manipulate buffer lists.

Oh and yes, an 'append' operator/keyword/VM op would be a big win
for the table approach (a size operator wouldn't necessarily).
But let's not reopen that discussion again.

> >What would upvalues be replaced with? Surely Lua is not abandoning 
> >closures! That is one thing that has gotten Lua a lot of press for 
> >being hip and cutting edge :-)
> 
> Function environments, apparently, now that CFunctions also have them. 
> I don't believe that Lua will abandon closures, but CFunction upvalues 
> might be regarded as a holdover.

If you reread that thread, this came in the form of a question
from Mark Hamburg. The Lua authors have not made any comment on
this issue AFAIK.

I vetoed:
| I do use multiple upvalues. Removing this feature would be rather
| inconvenient (and slower, too). There is no space penalty since
| upvalues are allocated at the end of the closure object. Removing
| C function upvalues would save only very little code in the Lua core
| (e.g. because Lua functions still need upvalues). There is not much
| to be gained.
|
| Put another way: now Lua functions and C functions both have an
| environment and both have upvalues. This increases orthogonality,
| which is a good thing (most of the time).

I should add: there are several semantic differences between
function environments and upvalues (e.g. inheritance). The former
are not a proper replacement for the latter IMHO.

Bye,
     Mike