Re: introducing luaSuper

[David Manura <dm.lua@...>]

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.