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

[Tim Hill <drtimhill@...>]

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 "from" syntax I suggested has the advantage of preserving existing semantics. For example, if a table field is not defined the corresponding local will get nil, just as with an explicit assignment.

I don't see how you can deduce "constancy" (by which I assume you mean "must be present", rather than "fixed value at compile time") at compile time, you would have to explicitly declare it .. but where could you do that? "foo.x" is NOT a table with a field "x" .. it's just shorthand for foo["x"] which is a dynamic lookup on a dynamic table (both known only at run time). The problem here isn't so much that "x" is known, it's that the TABLE is not known until run time. Any compile time syntax you could create could only decorate a field NAME, not a field in a table. For example:

t1, t2 = {}
if (some_boolean) then
	mytable = t1
else
	mytable = t2
end
mytable.x = "foo"
local x = mytable.x

How could this be made constant at compile time? "x" here is just a field name, "mutable" is just a variable. There is no compile-time way to say "this table must have a field named "x" because in Lua there is no "this table" at compile time.

--Tim



On May 18, 2013, at 2:09 PM, Andres Perera <andres.p@zoho.com> wrote:

> On Sat, May 18, 2013 at 4:22 PM, Tim Hill <drtimhill@gmail.com> wrote:
>> I'm not even sure if this would be possible?
>> 
>> local variables are assigned to stack slots at compile time, so something like this would require the compiler to know the contents of a table at compile-time, not run-time, to determine the set of locals to create. Since tables are dynamic, this means the compiler would have to know, in advance, what the contents of a table was going to be at run time. Does not compute.
> 
> Tables could be given a `constant' attribute over their keys, either
> by deduction, or in the case of what's favorable for tables holding
> module entries, by an explicit token.
> 
> The concept wouldn't have to bask in more complexity than providing
> means for the compiler to asses the number of keys for the purposes of
> CT-"table globbing", which in turn is just a subset of pattern
> matching.
> 
> Also, directly exposing tables to env-controlled programs is more
> performant this way than with metamethods that check for "write
> permissions".
>