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

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

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.

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

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.

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

The reference itself, not the table, bears the immutable bit. The
standard could say something to the effect of "aliasing an immutable
table with a non const pointer is bad so don't do it".

I'm not of the opinion that because; e.g., you can cast away to your
heart's content:

char const * x = "foo"; char *y = (char *)x;

that means that the whole system is useless. In order words, I think
you're panicking.