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

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

On Sat, May 18, 2013 at 11:10 PM, Tim Hill <drtimhill@gmail.com> wrote:
>
>> Which is why you would declare the table `constant', the same way you
>> declare high-traffic variables `local', the same way C programmers of
>> age misguidedly declared variables `register'.
>
> Declaring a table constant makes no difference. Thee issue is the VARIABLE that refers to that table, not the fact that the table is references is constant or not. In my example, the compiler still has to trace the content of "t1" back to a constant declaration by (expensive) static analysis, regardless of it's "constness".

Then there are two different concepts of const at play:

* Once a variable is declared const, it is beyond strongly typed: it
can't refer to another object, even if the new object is a table.

* Once a table is declared const, it's keys may not change, and the
keys must be known at CT.

This is, in C, the difference between: const type * and type * const,
but for the purposes of this proposal, a lua declaration such as:

constant t = {}

sets both the variable name and the table to const

>
> As I said, it's possible I've missed your point .. some code examples to illustrate your proposal would help.
>
>> I do have to say that immutable tables could be vastly appreciated by the GC.
>
> Won't make much difference to the GC; inbound references will still need to be traced, as will outgoing ones from the const table (though these would not change from GC pass to pass).

If const is also overloaded to mean static--well intentioned, since it
happens to fit the usage of module tables and other module data for
that matter--the GC can also, in adittion to skip iterating through
the table, as you mentioned, assume the table will never be
deallocated.

>
>> IIRC, the JVM GC got a boost from allocating class tables differently
>> than other data, seeing that they are constant.
>
>
>