Re: [ANN] Lua 5.2.1 (work1) now available

[Coda Highland <chighland@...>]

> > No one here was promoting ropes as being the basic string
> > implementation for Lua. It was being proposed specifically as an
> > intermediate structure for the concatenation operator, to be flattened
> > on demand when the object is needed in a string context (except for
> > more concatenation, and possibly getting the length as it's a common
> > enough idiom to append until a certain size is reached).
>
> IMHO it's the job of a JIT compiler to create such an intermediate
> structure, should the need arise. Neither the user should have to
> deal with it, nor the VM as a whole. A simple growable buffer
> looks like a better choice than ropes for that.

It's also a reasonably common idiom to assemble sub-units and then
concatenate those into a larger document. This is where ropes really
start to shine, as ropes can themselves be concatenated to each other
(as opposed to just rope..string) with minimal overhead. But it may be
that you're right -- it may be that for the general case a buffer with
some sort of smart growth strategy could be better than a linked list
of strings approach for the actual memory management side of things.

But that ultimately ends up in the same kind of implementation on the
API side -- a secondary data type returned by the concatenation
operator that gets coerced to a "normal" string when needed. It is
after all probably not desirable to make ALL string objects work this
way.

/s/ Adam