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

["Thomas Jericke" <tjericke@...>]

-----Original Message----- 
> From: "Andres Perera" <andres.p@zoho.com> 
> To: "Lua mailing list" <lua-l@lists.lua.org> 
> Date: 23-05-2013 17:09 
> Subject: Re: Is there a kernel patch for creating local variables programmatically? 
> 
> 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:
> >
> > 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. 

It's not a blocker, but it has to be implemented. "require" supports custom loaders, I would expect that feature from import too.

It's not that I oppose an "import" feature, I'm just pointing out what implication it would have.

> I don't see a case being made against shimmying the teller to
> the window 2 feet away, either. :)

You really like to talk in riddles, don't you?

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

Not in the case of generated scripts. In those cases the scripts maybe don't even exist as files but only as strings in memory. Of course modules aren't usually generated scripts, so it probably will work in most cases.

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

I got this part, but not your last sentence.

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


Hopefully not, the bytecode of modules should still be shared and only compiled once, no need to compile imported modules in each Lua file compilation.
--
Thomas