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

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

On Sat, May 18, 2013 at 10:19 PM, Tim Hill <drtimhill@gmail.com> wrote:
> Well I guess we shall have to disagree .. my understanding is that the
> original concern was to use the fields of a table to synthesize, at compile
> time, a set of local variables, thus contracting the common "local foo =
> table.foo …" idiom.
>
> This can be made to work pretty easily:
>
> local … from { a = 10, b = 20 } -- here "..." means to create names from the
> table fields.
>
> This is far harder:
>
> t1 = { a = 10, b = 20 }
> -- lots of other code here
> local … from t1
>
> The 2nd example needs static analysis, something that is expensive to do,
> and in any case depending upon the "lots of other code" may be
> indeterminate. That was my point.

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

I'm not seeing a problem at all, frankly.

I do have to say that immutable tables could be vastly appreciated by the GC.

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