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

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

On Thu, May 23, 2013 at 6:21 AM, Thomas Jericke <tjericke@indel.ch> wrote:
> On 05/23/2013 03:41 AM, Andres Perera wrote:
>>
>> On Tue, May 21, 2013 at 1:44 AM, Thomas Jericke <tjericke@indel.ch> wrote:
>>>
>>> On 05/18/2013 08:06 PM, Dirk Laurie wrote:
>>>>
>>>> Often on this list voices have gone up proposing a language addition
>>>> that would allow one to automate the following process:
>>>>
>>>>       local concat,insert,remove,pack,sort,unpack=
>>>>          table.concat, table.insert, table.remove, table.pack,
>>>>          table.sort, table.unpack
>>>>
>>>> by saying Pythonically
>>>>
>>>>       from table import *
>>>>
>>>> or whatever.  Has anybody ever actually produced a kernel patch that
>>>> implements something of the kind?
>>>>
>>> As been said, this is not possible. Lua is not aware what members the
>>> table
>>> has at compile time, locals accesses are generated at compile time
>>> (that's
>>> why I like them so much).
>>> In the case of 'require()' that would actually mean, that Lua must be
>>> aware
>>> of other files at compile time, which it isn't at the moment. Currently
>>> you
>>> can compile Lua scripts each by its own, and actually I think that is a
>>> nice
>>> feature. I am not sure if Lua should give up this feature for a "import
>>> *"
>>> statement. A lot of freedom to give up just to avoid some typing.
>>
>> I am not sure why a require() alternative with semantics that allows
>> static assertions implies the current one should be replaced.
>
> It doesn't. But calling it "import" and leaving the current require() as it
> is, doesn't change the implications I wrote. Any Lua scripts using the
> "import" statement can not be compiled by itself. Which means a compiler
> needs to have some kind of searcher to find imported scripts similar to
> those that require uses.

I don't see the inclusion of the module-resolver as an important
blocker. I don't see a case being made against shimmying the teller to
the window 2 feet away, either. :)

> Of course this only has implications if you use the
> Lua compiler separately. But I do that, I even allow Lua scripts to be
> compiled on a different architectury (I modified the Lua compiler to be able
> to cross compile).

I see now... but presumably you keep a copy of the modules your script
depends on, for testing and development purposes.

>
> Now this might not be the most important feature of Lua, but I just wanted
> to say that it is quite nice and handy in some cases.
>
>>
>> So far these concerns don't really align with the unconditional usage
>> of modules; dynamism is being preferred where it isn't beneficial.
>
> I am not sure what your point is. Could you please elaborate?

This is unconditional:

local t = require("foo")

This isn't:

if lua_version > 5100 then
  local t = require("foo")
else
 local t = require("bar")
end

With import semantics, the bytecode would be larger as it compiles both modules.