Is there a kernel patch for creating local variables programmatically?

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Is there a kernel patch for creating local variables programmatically?

Dirk Laurie-2
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?

Reply | Threaded
Open this post in threaded view
|

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

Tim Hill
I'm not even sure if this would be possible?

local variables are assigned to stack slots at compile time, so something like this would require the compiler to know the contents of a table at compile-time, not run-time, to determine the set of locals to create. Since tables are dynamic, this means the compiler would have to know, in advance, what the contents of a table was going to be at run time. Does not compute.

The only thing I think would work is a bit of syntactic sugar. Something like:

local a, b, c from some_table

Which the compiler could re-write as:

local a, b, c = some_table.a, some_table.b, some_table.c

This is robust at both compile and run-time given Luas handling of undefined table items, but doesn't give you the "wildcard" you were suggesting.

--Tim



On May 18, 2013, at 1:06 PM, Dirk Laurie <[hidden email]> 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?
>


Reply | Threaded
Open this post in threaded view
|

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

Andres Perera
On Sat, May 18, 2013 at 4:22 PM, Tim Hill <[hidden email]> wrote:
> I'm not even sure if this would be possible?
>
> local variables are assigned to stack slots at compile time, so something like this would require the compiler to know the contents of a table at compile-time, not run-time, to determine the set of locals to create. Since tables are dynamic, this means the compiler would have to know, in advance, what the contents of a table was going to be at run time. Does not compute.

Tables could be given a `constant' attribute over their keys, either
by deduction, or in the case of what's favorable for tables holding
module entries, by an explicit token.

The concept wouldn't have to bask in more complexity than providing
means for the compiler to asses the number of keys for the purposes of
CT-"table globbing", which in turn is just a subset of pattern
matching.

Also, directly exposing tables to env-controlled programs is more
performant this way than with metamethods that check for "write
permissions".

Reply | Threaded
Open this post in threaded view
|

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

Tim Hill
But such a change is a MUCH deeper change to Lua than just making it easier to write the local declarations. Tables have no existence at compile time in the current model, hence the concept of "{}" as a table CONSTRUCTOR and not a table LITERAL.

The "from" syntax I suggested has the advantage of preserving existing semantics. For example, if a table field is not defined the corresponding local will get nil, just as with an explicit assignment.

I don't see how you can deduce "constancy" (by which I assume you mean "must be present", rather than "fixed value at compile time") at compile time, you would have to explicitly declare it .. but where could you do that? "foo.x" is NOT a table with a field "x" .. it's just shorthand for foo["x"] which is a dynamic lookup on a dynamic table (both known only at run time). The problem here isn't so much that "x" is known, it's that the TABLE is not known until run time. Any compile time syntax you could create could only decorate a field NAME, not a field in a table. For example:

t1, t2 = {}
if (some_boolean) then
        mytable = t1
else
        mytable = t2
end
mytable.x = "foo"
local x = mytable.x

How could this be made constant at compile time? "x" here is just a field name, "mutable" is just a variable. There is no compile-time way to say "this table must have a field named "x" because in Lua there is no "this table" at compile time.

--Tim



On May 18, 2013, at 2:09 PM, Andres Perera <[hidden email]> wrote:

> On Sat, May 18, 2013 at 4:22 PM, Tim Hill <[hidden email]> wrote:
>> I'm not even sure if this would be possible?
>>
>> local variables are assigned to stack slots at compile time, so something like this would require the compiler to know the contents of a table at compile-time, not run-time, to determine the set of locals to create. Since tables are dynamic, this means the compiler would have to know, in advance, what the contents of a table was going to be at run time. Does not compute.
>
> Tables could be given a `constant' attribute over their keys, either
> by deduction, or in the case of what's favorable for tables holding
> module entries, by an explicit token.
>
> The concept wouldn't have to bask in more complexity than providing
> means for the compiler to asses the number of keys for the purposes of
> CT-"table globbing", which in turn is just a subset of pattern
> matching.
>
> Also, directly exposing tables to env-controlled programs is more
> performant this way than with metamethods that check for "write
> permissions".
>


Reply | Threaded
Open this post in threaded view
|

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

Jay Carlson

On May 18, 2013, at 6:05 PM, Tim Hill wrote:

> But such a change is a MUCH deeper change to Lua than just making it easier to write the local declarations. Tables have no existence at compile time in the current model,

Aw, I was gonna say that.

Here's a different way of thinking of it. Compilation is a pure function from a stream to a Lua function. The same text always produces functions which have indistinguishable behavior.

The "no macros" theorem can be derived from that.

Jay


Reply | Threaded
Open this post in threaded view
|

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

Jay Carlson

On May 18, 2013, at 6:22 PM, Jay Carlson wrote:

> Compilation is a pure function from a stream to a Lua function. The same text always produces functions which have indistinguishable behavior.
>
> The "no macros" theorem can be derived from that.

Well, strictly speaking you could have a certain kind of file-scoped macros. But you can't import them, which severely limits their utility.
Reply | Threaded
Open this post in threaded view
|

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

Andres Perera
In reply to this post by Tim Hill
On Sat, May 18, 2013 at 5:35 PM, Tim Hill <[hidden email]> wrote:
> But such a change is a MUCH deeper change to Lua than just making it easier to write the local declarations. Tables have no existence at compile time in the current model, hence the concept of "{}" as a table CONSTRUCTOR and not a table LITERAL.

The change is that a set of table constructors can now be asked to
give a maximum number of members, at CT. Non-constant tables return
"undeterminate". The prodding for maximum number of members happens
when the `from' operator is parsed.

>
> The "from" syntax I suggested has the advantage of preserving existing semantics. For example, if a table field is not defined the corresponding local will get nil, just as with an explicit assignment.
>
> I don't see how you can deduce "constancy" (by which I assume you mean "must be present", rather than "fixed value at compile time") at compile time, you would have to explicitly declare it ..

You can deduce immutability by analyzing the life-time of a table...
in the case of modules, the life-time is indeterminate, or potentially
program-lasting, which is why the `constant' attribute comes in handy.

> but where could you do that? "foo.x" is NOT a table with a field "x" .. it's just shorthand for foo["x"] which is a dynamic lookup on a dynamic table (both known only at run time). The problem here isn't so much that "x" is known, it's that the TABLE is not known until run time. Any compile time syntax you could create could only decorate a field NAME, not a field in a table. For example:
>
> t1, t2 = {}
> if (some_boolean) then
>         mytable = t1
> else
>         mytable = t2
> end
> mytable.x = "foo"
> local x = mytable.x
>
> How could this be made constant at compile time? "x" here is just a field name, "mutable" is just a variable. There is no compile-time way to say "this table must have a field named "x" because in Lua there is no "this table" at compile time.

The reference itself, not the table, bears the immutable bit. The
standard could say something to the effect of "aliasing an immutable
table with a non const pointer is bad so don't do it".

I'm not of the opinion that because; e.g., you can cast away to your
heart's content:

char const * x = "foo"; char *y = (char *)x;

that means that the whole system is useless. In order words, I think
you're panicking.

Reply | Threaded
Open this post in threaded view
|

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

Jay Carlson

On May 18, 2013, at 6:49 PM, Andres Perera wrote:

> On Sat, May 18, 2013 at 5:35 PM, Tim Hill <[hidden email]> wrote:
>> But such a change is a MUCH deeper change to Lua than just making it easier to write the local declarations. Tables have no existence at compile time in the current model, hence the concept of "{}" as a table CONSTRUCTOR and not a table LITERAL.
>
> The change is that a set of table constructors can now be asked to
> give a maximum number of members, at CT. Non-constant tables return
> "undeterminate". The prodding for maximum number of members happens
> when the `from' operator is parsed.

require() happens at runtime, not compile-time. You'd have to switch to semantics closer to  #include, I think. @splicing in an external AST would be cleaner and work as well.

Jay


Reply | Threaded
Open this post in threaded view
|

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

Tim Hill
In reply to this post by Andres Perera

> On Sat, May 18, 2013 at 5:35 PM, Tim Hill <[hidden email]> wrote:
>> But such a change is a MUCH deeper change to Lua than just making it easier to write the local declarations. Tables have no existence at compile time in the current model, hence the concept of "{}" as a table CONSTRUCTOR and not a table LITERAL.
>
> The change is that a set of table constructors can now be asked to
> give a maximum number of members, at CT. Non-constant tables return
> "undeterminate". The prodding for maximum number of members happens
> when the `from' operator is parsed.

I confess to being rather confused on what you are suggesting. Yes, at CT the number of elements in a constructor is know, but so what? The goal here is to have a construct that can compactly map a set of named table fields to a set of named local variables (as we all know, a common Lua idiom). Debug library aside, local variable names are known only at CT, while table field names are known only at RT. I don't quite see that you are proposing that will change this.

> You can deduce immutability by analyzing the life-time of a table...
> in the case of modules, the life-time is indeterminate, or potentially
> program-lasting, which is why the `constant' attribute comes in handy.

Hmmm … how would you do that? Table lifetime is only really resolvable at runtime .. that's what GC is all about.

What you have at CT is a constructor that creates a new table each time it is executed at RT. A certain subset of such constructors can be said to be "prototypes" in that each invocation generates a table with the same set of fields each time (put another way, the field names for each element are known at compile time and therefore invariant at run time).

So far so good. Now let's look at the two proposals:

First, the original "wildcard" model, with something like:

local from table.* -- Create a set of locals using wildcard matching names from the table.

Second, my simpler "list" model:

local a, b, c from table -- Create the specified locals from corresponding fields in the table.

The problem with the first approach is it requires the compiler to be able to know the expansion of "table.*" at CT. Now, even if we DO have one of our "prototype" constructors as above, how can the compiler know this? The table in question is a variable, and understanding the contents at CT requires static analysis, and even so will only work in a very small subset of cases (most of which, to be honest, are not very interesting anyway). As has been noted, "require", the most common source of these tables, is a RT operation; the contents of the table returned by it is simply not available to the compiler.

--Tim


Reply | Threaded
Open this post in threaded view
|

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

Andres Perera
On Sat, May 18, 2013 at 9:31 PM, Tim Hill <[hidden email]> wrote:

>
>> On Sat, May 18, 2013 at 5:35 PM, Tim Hill <[hidden email]> wrote:
>>> But such a change is a MUCH deeper change to Lua than just making it easier to write the local declarations. Tables have no existence at compile time in the current model, hence the concept of "{}" as a table CONSTRUCTOR and not a table LITERAL.
>>
>> The change is that a set of table constructors can now be asked to
>> give a maximum number of members, at CT. Non-constant tables return
>> "undeterminate". The prodding for maximum number of members happens
>> when the `from' operator is parsed.
>
> I confess to being rather confused on what you are suggesting. Yes, at CT the number of elements in a constructor is know, but so what? The goal here is to have a construct that can compactly map a set of named table fields to a set of named local variables (as we all know, a common Lua idiom). Debug library aside, local variable names are known only at CT, while table field names are known only at RT. I don't quite see that you are proposing that will change this.

You are conflating concerns. Strictly speaking, the original problem
was to determine the space needed for local slots, therefore the only
relevant datum is the number of elements. The problem with field names
is orthogonal to that.

Secondly, the problem with field names is only a problem if I
entertain the notion that module writers like to index their export
tables with dynamic (ie., non string-constant names).

In order to circumvent the ridiculousness of that situation, a table
declaration with the constant qualifier must have CT-known names.

>
>> You can deduce immutability by analyzing the life-time of a table...
>> in the case of modules, the life-time is indeterminate, or potentially
>> program-lasting, which is why the `constant' attribute comes in handy.
>
> Hmmm … how would you do that? Table lifetime is only really resolvable at runtime .. that's what GC is all about.

You are dismissing analysis of tables who 1. don't get their members
aliased, and 2. exist (has references to) "up to" file scope. I'm
merely suggesting that block, function scope, and file scope lists are
eligible for less expensive analysis than tables that potentially
exist cross-module boundaries.

Reply | Threaded
Open this post in threaded view
|

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

Tim Hill
Well I guess we shall have to disagree .. my understanding is that the original concern was to use the fields of a table to synthesize, at compile time, a set of local variables, thus contracting the common "local foo = table.foo …" idiom.

This can be made to work pretty easily:

local … from { a = 10, b = 20 } -- here "..." means to create names from the table fields.

This is far harder:

t1 = { a = 10, b = 20 }
-- lots of other code here
local … from t1

The 2nd example needs static analysis, something that is expensive to do, and in any case depending upon the "lots of other code" may be indeterminate. That was my point.

--Tim


On May 18, 2013, at 7:29 PM, Andres Perera <[hidden email]> wrote:

You are conflating concerns. Strictly speaking, the original problem
was to determine the space needed for local slots, therefore the only
relevant datum is the number of elements. The problem with field names
is orthogonal to that.

Reply | Threaded
Open this post in threaded view
|

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

Andres Perera
On Sat, May 18, 2013 at 10:19 PM, Tim Hill <[hidden email]> wrote:

> Well I guess we shall have to disagree .. my understanding is that the
> original concern was to use the fields of a table to synthesize, at compile
> time, a set of local variables, thus contracting the common "local foo =
> table.foo …" idiom.
>
> This can be made to work pretty easily:
>
> local … from { a = 10, b = 20 } -- here "..." means to create names from the
> table fields.
>
> This is far harder:
>
> t1 = { a = 10, b = 20 }
> -- lots of other code here
> local … from t1
>
> The 2nd example needs static analysis, something that is expensive to do,
> and in any case depending upon the "lots of other code" may be
> indeterminate. That was my point.

Which is why you would declare the table `constant', the same way you
declare high-traffic variables `local', the same way C programmers of
age misguidedly declared variables `register'.

I'm not seeing a problem at all, frankly.

I do have to say that immutable tables could be vastly appreciated by the GC.

IIRC, the JVM GC got a boost from allocating class tables differently
than other data, seeing that they are constant.

Reply | Threaded
Open this post in threaded view
|

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

Tim Hill

> Which is why you would declare the table `constant', the same way you
> declare high-traffic variables `local', the same way C programmers of
> age misguidedly declared variables `register'.

Declaring a table constant makes no difference. Thee issue is the VARIABLE that refers to that table, not the fact that the table is references is constant or not. In my example, the compiler still has to trace the content of "t1" back to a constant declaration by (expensive) static analysis, regardless of it's "constness".

As I said, it's possible I've missed your point .. some code examples to illustrate your proposal would help.

> I do have to say that immutable tables could be vastly appreciated by the GC.

Won't make much difference to the GC; inbound references will still need to be traced, as will outgoing ones from the const table (though these would not change from GC pass to pass).

> IIRC, the JVM GC got a boost from allocating class tables differently
> than other data, seeing that they are constant.


Reply | Threaded
Open this post in threaded view
|

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

Andres Perera
On Sat, May 18, 2013 at 11:10 PM, Tim Hill <[hidden email]> wrote:
>
>> Which is why you would declare the table `constant', the same way you
>> declare high-traffic variables `local', the same way C programmers of
>> age misguidedly declared variables `register'.
>
> Declaring a table constant makes no difference. Thee issue is the VARIABLE that refers to that table, not the fact that the table is references is constant or not. In my example, the compiler still has to trace the content of "t1" back to a constant declaration by (expensive) static analysis, regardless of it's "constness".

Then there are two different concepts of const at play:

* Once a variable is declared const, it is beyond strongly typed: it
can't refer to another object, even if the new object is a table.

* Once a table is declared const, it's keys may not change, and the
keys must be known at CT.

This is, in C, the difference between: const type * and type * const,
but for the purposes of this proposal, a lua declaration such as:

constant t = {}

sets both the variable name and the table to const

>
> As I said, it's possible I've missed your point .. some code examples to illustrate your proposal would help.
>
>> I do have to say that immutable tables could be vastly appreciated by the GC.
>
> Won't make much difference to the GC; inbound references will still need to be traced, as will outgoing ones from the const table (though these would not change from GC pass to pass).

If const is also overloaded to mean static--well intentioned, since it
happens to fit the usage of module tables and other module data for
that matter--the GC can also, in adittion to skip iterating through
the table, as you mentioned, assume the table will never be
deallocated.

>
>> IIRC, the JVM GC got a boost from allocating class tables differently
>> than other data, seeing that they are constant.
>
>
>

Reply | Threaded
Open this post in threaded view
|

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

Tim Hill
> Then there are two different concepts of const at play:
>
> * Once a variable is declared const, it is beyond strongly typed: it
> can't refer to another object, even if the new object is a table.
>
> * Once a table is declared const, it's keys may not change, and the
> keys must be known at CT.
>
> This is, in C, the difference between: const type * and type * const,
> but for the purposes of this proposal, a lua declaration such as:
>
> constant t = {}
>
> sets both the variable name and the table to const

Yep, well aware of the various uses of const in C as well as static in Java etc etc.

My point throughout has not been if its POSSIBLE to do this, it's been the scope of the changes implied. My original "local … from" was nothing more than simple syntactic sugar to (a) decrease typing and (b) reduce errors caused by mis-matching of local names to a long list of table field names. By itself, this has some legs imho, and the changes made to the language are trivial and have no broad-reaching side effects beyond the (always risky) introduction of a new keyword.

What is the scope of "t" in your example? If it's global, there are all sorts of issues. Consider this:
constant t = {}
_G["t"] = 100

What you are really suggesting I think, at its root, is an immutable table (think strings) whose content is known at compile time. That is a very significant change to the language, with broad-reaching consequences, a lot of very subtle changes, and some significant additional complexity to the compiler. It is also, imho, moving Lua away from the "dynamic" model and toward a more compiler-centric declarative, strongly typed model … and I for one don't feel very comfortable with that thought.

--Tim


Reply | Threaded
Open this post in threaded view
|

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

Thomas Jericke
In reply to this post by Andres Perera
On 05/19/2013 03:53 AM, Andres Perera wrote:
> This is, in C, the difference between: const type * and type * const,
> but for the purposes of this proposal, a lua declaration such as:
> constant t = {} sets both the variable name and the table to const
That would then mean, you could not use those tables with require as
require can't know what it will return before it is called. So it can't
be static const.

Not be able to use require spoils the whole point of an import statement.
--
Thomas

Reply | Threaded
Open this post in threaded view
|

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

Thomas Jericke
In reply to this post by Dirk Laurie-2
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.

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

Reply | Threaded
Open this post in threaded view
|

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

steve donovan
On Tue, May 21, 2013 at 8:14 AM, Thomas Jericke <[hidden email]> wrote:
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.

Naturally, this has been done ;)

--- mmath.lua
-- shows how a macro module pulled in with require_
-- can return a substitution value. In this case,
-- it would be better to use include_, but this
-- method is more general
return function()
    return 'local sin,cos = math.sin, math.cos\n'
end

-- test-require.lua
require_ 'mmath'

print(sin(1.2) + cos(0.3))

Anything can be loaded at pre-compile expansion time, so it can work with any require.

However, it involves the external dependency LuaMacro as a preprocessor

 

Reply | Threaded
Open this post in threaded view
|

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

Andres Perera
In reply to this post by Thomas Jericke
On Tue, May 21, 2013 at 1:44 AM, Thomas Jericke <[hidden email]> 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.

So far these concerns don't really align with the unconditional usage
of modules; dynamism is being preferred where it isn't beneficial.

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

Reply | Threaded
Open this post in threaded view
|

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

Thomas Jericke
On 05/23/2013 03:41 AM, Andres Perera wrote:

> On Tue, May 21, 2013 at 1:44 AM, Thomas Jericke <[hidden email]> 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
>>
>>


12