lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

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



If Lua really once will get a macro extension, it is highly possible that
such things would be possible, assuming that the Lua macro language will run
pre-compilation.
--
Thomas