[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Is there a kernel patch for creating local variables programmatically?
- From: Thomas Jericke <tjericke@...>
- Date: Thu, 23 May 2013 10:51:56 +0000
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. 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).
On Tue, May 21, 2013 at 1:44 AM, Thomas Jericke <email@example.com> 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:
table.concat, table.insert, table.remove, table.pack,
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.
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