Asko Kauppi writes:
The work on luaSuper is approaching release, and I would like to
share some of it here
I tend to agree with what Fabien wrote below in the "Lua is not
skin deep"
thread in favor of syntax mods being expressed in Lua rather than C/
C++ for the
practical reason of reducing maintenance costs. Ease of use is one
of your
stated design goals after all. Still, there are some advantages to
patching the
parser in C, and maybe your approach could reduce the complexity of
that.
Fabien writes:
I'm obviously biased [toward] metalua here, but it seems to me
that source parsing can always be taken out of the critical
optimization path, so it ought to be dealt with in Lua rather
than in portable assembler, if it is intended to be tweaked by
users. C maintenance costs are much higher than lua's, so it
makes sense to patch the VM, but not the compiler IMO.
Asko Kauppi writes:
This is how it goes:
luas -s select demo.lua # loads demo.lua with syntax mods from
'luas_select.so'
or, one can make demo.lua load the syntax mods automatically, by
having the following shebang line:
#!/.../luas -s select
Here, we need to compile each syntax mod to a shared object in a
platform
dependent way. Then we need to specify it on the command line or
edit a
system-dependent absolute path in the script. It would seem to me
that each
module should itself know which syntax mod(s) it needs, possibly
specified with
a compiler directive, and the interpreter should know how to find
them:
-- mycode.lua
#use select
local oc = require "othercode"
function test(...)
return #..., ...[1], oc()
end
print(test(2,3,4))
print(test(2,3,4))
-- othercode.lua
#use incrementops
local x = 0
return function()
x += 5
return x
end
$ LUA_CPATH=... luas mycode.lua
- made in C++ (about 2500 lines, 4 .cpp files)
- parsing speed should be similar to regular Lua parser,
_even_ when the syntax is modified...
Performance and ease of making syntax modifications have been the
design goals
Could the syntax mod descriptions be written in Lua, using Lua as a
data
description language, but processed in C/C++ (like what LPeg does),
while still
maintaining performance? Those writing code in Lua must have
already accepted
the performance of Lua.
