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

[Dirk Laurie <dirk.laurie@...>]

Sorry for top-posting, but I'm not really responding to any particular
point made before.

We all have our little eccentricities, e.g. people influenced by Steve
always do `local append = table.insert` to be used for the two-parameter
flavour, whereas many others don't feel the need.

I don't see syntactic sugar for one particular eccentricity
(defining locals with exactly the same name as some globals or
upvalues) as sufficiently widely applicable to justify adding syntax
the Lua language.

What we should rather be looking for, is something with much
wider application that happens to be a convenient way of also
implementing this feature.

2013/11/17 Sir Pogsalot <sir.pogsalot@gmail.com>:
> If the number of locals must be known at compile time, import() would have
> to be of the form:
>
>
> import(io, 'read', 'write', 'setvbuf')
>
> This way the the contents of io would not have to be known at compile-time,
> and the locals (read, write, setvbuf) would either become references to the
> associated values in io or nil?
>
> The only problem is I really like the idea of having user-supplied prefix
> for certain tables.
>
> So if we require that a list of keys for localizing values is always there,
> it becomes the import(io, { 'read', 'write' }, 'optional_prefix_') form
> again.
>
> Beyond that... I read Rena's reply and I could see this being potentially
> convenient:
>
> local tins, trem, tcat = from(table, 'insert, 'remove', 'cat')
>
> That's easy as hell to write in Lua without touching any C... the problem is
> the user might be inclined to write trem rather than tremove, and
> third-parties might not understand the obvious shortening.  People would be
> inclined to come up with shorter identifiers with a from() like that..
>
> Adding a pad of unused locals to functions for the purpose of redefining
> them with an import() is out of the question, that would be an inefficiency
> of fun proportions. :]
>
> Blah.  Save us Roberto, you're our only hope! <3
>
>
> On Sun, Nov 17, 2013 at 8:53 AM, Sir Pogsalot <sir.pogsalot@gmail.com>
> wrote:
>>
>> 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.
>>>
>>
>