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

[Tim Hill <drtimhill@...>]

(top-posting as general comment…)

Isn’t this really a circular discussion? It seems to me there are two reasons for assigned a function in a table to a local:
— Brevity (easier to type “foo” than “some table.somefunction”)
— Performance (access to locals is faster than access to globals or table values with string keys)

Now, brevity you can get with globals, albeit at the expense of pollution of the _ENv space. Performance, however, comes from the fact that locals have significantly more processing handled at compile-time than run-time (replacement of slow names/table lookups with fast stack slot accesses).

But any attempt to automatically assign table values to locals has to happen at run-time, and this will inevitably entail late binding of local names, which will in turn involve name look-ups at run-time, which in turn will re-introduce the performance issue that the use of locals was trying to avoid in the first place.

Of course, it might be possible to interrogate a table at compile time, but this is fraught with issues (compile context vs run-time context differences, early vs late binding etc etc), and has been discussed here before .. it leads to quite a bit of change to the language and compiler behavior, most of which is fragile. So really what we have is potentially a VERY big language change to avoid some typing.

For myself, if I do have a bunch of “local x = tx.” statements in production code, I just wrap them up into a generator macro (I generally use a macro processor with my Lua source code to help out with stuff like this). This reduces typing but doesn’t mess with the language.

—Tim

On Nov 18, 2013, at 11:56 AM, Sean Conner <sean@conman.org> wrote:

> It was thus said that the Great Sir Pogsalot once stated:
>> I want to thank Petite Abeille for being the most contributory, the 2nd
>> approach was creative.  I would probably stick with the from() I posted,
>> but I thought your code was really thought-provoking and I appreciate you
>> putting more code to this thread. :]
>> 
>> Most of the replies boil down to:
>> 4) have an external script generate the 'local a = mod.a' list
>> 
>> My response:
>> 4) Running an external script to generate the preamble sounds trendy...
> 
>  Trendy?  As far as I know, I'm the first to suggest that, in this thread,
> and I've seen this topic come up a few times before.  How is this trendy? 
> In my opinion, changing the semantics of the language is the "trendy" thing
> to do (since it keeps coming up over and over again).
> 
>> The problem is these local lines.  I see a lot of them and they're not
>> easy to 'skim'.  It makes it difficult to review others' code if you're
>> making sure they use everything they've referenced.
> 
>  Again, there are tools to check for unused variables.  
> 
>> Things to remember:
>> - I'm trying to avoid messing with _ENV
>> - I'm trying to create locals in batch
>> - I want to create locals [not globals!!!] with import()
>> - I want the ability to provide a prefix to the generated local identifiers
>> - I want to be able to specify a list of what to localize from the table
> 
>  And again, how does the script not provide all those?  Why *MUST* this be
> in the language?
> 
>  -spc
> 
>