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

[Tim Hill <drtimhill@...>]

> 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 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.

What you have at CT is a constructor that creates a new table each time it is executed at RT. A certain subset of such constructors can be said to be "prototypes" in that each invocation generates a table with the same set of fields each time (put another way, the field names for each element are known at compile time and therefore invariant at run time).

So far so good. Now let's look at the two proposals:

First, the original "wildcard" model, with something like:

local from table.*	-- Create a set of locals using wildcard matching names from the table.

Second, my simpler "list" model:

local a, b, c from table		-- Create the specified locals from corresponding fields in the table.

The problem with the first approach is it requires the compiler to be able to know the expansion of "table.*" at CT. Now, even if we DO have one of our "prototype" constructors as above, how can the compiler know this? The table in question is a variable, and understanding the contents at CT requires static analysis, and even so will only work in a very small subset of cases (most of which, to be honest, are not very interesting anyway). As has been noted, "require", the most common source of these tables, is a RT operation; the contents of the table returned by it is simply not available to the compiler.

--Tim