Re: Suggestion for 5.3: import() for creating a "slew" of locals

[Sir Pogsalot <sir.pogsalot@...>]

Hmm, I had not realized that the number of locals to allocate for (including the `local a = module.a') was determined at compile time.  This would make sense, but it seems to strongly imply adding locals at runtime is impossible :(

I thought this might be the case, so this is why I was hoping upstream might know something magical you can do with the VM to support this for 5.3 :(

It would follow that similarly the number of upvalues are determined at compile time and not runtime?

I really wish this localize/import() were possible :(

On Sun, Nov 17, 2013 at 8:33 AM, steve donovan <steve.j.donovan@gmail.com> wrote:

On Sun, Nov 17, 2013 at 10:00 AM, Sir Pogsalot <sir.pogsalot@gmail.com> wrote:
> - localize() instead of import() so it doesn't get confused as having some
> function like require()
> - I'm not saying let's get rid of all the 'local a = module.a' lines, just
> provide this for when you need to create a lot of locals

This is definitely one of those feature requests that happens every
few years!  And yes, 'import' is confusing by association with Python.

But the point to understand is that this must be a purely _static_
operation at compile time. So implementing something like 'using
table.*' hits the problem of determining the contents of 'table' at
compile time.  So it would have to be an explicit list of entries to
localize, and understood as syntactical sugar for all those pesky
'local insert = table.insert' statements.

The issue then is that Lua is a 'reduced carbohydrates' language that
does not provide much sugar in the product, expecting users to add
their own.

Personally, I think such a construct would be useful, but unlikely to
get much traction.

steve d.