Re: Avoiding temporary tables

[Jay Carlson <nop@...>]

On Jun 1, 2013, at 2:02 PM, David Favro wrote:

> On 06/01/2013 11:36 AM, Jay Carlson wrote:
> [last reference]
>> I came across another situation where this is useful: lazy XML->LOM parsing. If a program drops the last reference to a subtree, any remaining XML yet to be parsed in that tree cannot affect the future of the program. The XML parser can go into a fast-forward mode, lexing but ignoring the contents of everything until the close tag. http://lua-users.org/wiki/LazyKit (although I probably should see if I have a releasable 5.2 version of that nine-year-old code....)
>> 
>> I don't know how expensive it would be to ask for the GC's help in answering "is this the last reference". This is one of the few times reference-counting implementations win.
> 
> I think that the need [if it exists, and I'm not saying that it does] would be better satisfied not by providing the reference count directly to the application code, but by supporting the desired operation directly, e.g. a table.shallow_clone() operation, which in addition to providing a more efficient implementation of a table-copy operation than can currrently be done without access to the internals, could also have an option to simply return the original if it is single-referenced.

Yes. That seems like a very nice operation to have for some programming styles. The trivial implementation always fails to guarantee uniqueness and thus does the shallow copy unconditionally.

The shallow copy operator doesn't help with early bailout on lazy table construction though. I mention this case because reflection on reachability is useful in control flow beyond the shallow copy optimization.

> Another detail that's not clear (to me, since I don't know the internals of Lua's GC/reference-counter) is whether a table-literal as function-call-argument actually keeps a reference that is not freed until after the function-call completes; if so, then the table inside the function might have two references, one for the parameter variable and one for the argument value.

I don't think it matters. The implementation can cheat and can't be caught, except through use of debug.*, or by having the called function set up a finalizer on the input table. I don't think there is a guarantee the parameter won't be finalized before return.

Jay