Re: Is there a kernel patch for creating local variables programmatically?

[Andres Perera <andres.p@...>]

On Sat, May 18, 2013 at 9:31 PM, Tim Hill <drtimhill@gmail.com> wrote:
>
>> On Sat, May 18, 2013 at 5:35 PM, Tim Hill <drtimhill@gmail.com> wrote:
>>> But such a change is a MUCH deeper change to Lua than just making it easier to write the local declarations. Tables have no existence at compile time in the current model, hence the concept of "{}" as a table CONSTRUCTOR and not a table LITERAL.
>>
>> The change is that a set of table constructors can now be asked to
>> give a maximum number of members, at CT. Non-constant tables return
>> "undeterminate". The prodding for maximum number of members happens
>> when the `from' operator is parsed.
>
> I confess to being rather confused on what you are suggesting. Yes, at CT the number of elements in a constructor is know, but so what? The goal here is to have a construct that can compactly map a set of named table fields to a set of named local variables (as we all know, a common Lua idiom). Debug library aside, local variable names are known only at CT, while table field names are known only at RT. I don't quite see that you are proposing that will change this.

You are conflating concerns. Strictly speaking, the original problem
was to determine the space needed for local slots, therefore the only
relevant datum is the number of elements. The problem with field names
is orthogonal to that.

Secondly, the problem with field names is only a problem if I
entertain the notion that module writers like to index their export
tables with dynamic (ie., non string-constant names).

In order to circumvent the ridiculousness of that situation, a table
declaration with the constant qualifier must have CT-known names.

>
>> You can deduce immutability by analyzing the life-time of a table...
>> in the case of modules, the life-time is indeterminate, or potentially
>> program-lasting, which is why the `constant' attribute comes in handy.
>
> Hmmm … how would you do that? Table lifetime is only really resolvable at runtime .. that's what GC is all about.

You are dismissing analysis of tables who 1. don't get their members
aliased, and 2. exist (has references to) "up to" file scope. I'm
merely suggesting that block, function scope, and file scope lists are
eligible for less expensive analysis than tables that potentially
exist cross-module boundaries.