uses of metalua for scripting

[spir <denis.spir@...>]

Hello,

I'm currently re-discovering metalua and find it great -- after a trip in the 
world of FP which let me explore parser combinators from a different perspective.

One of my remote projects is a scriptable game (à la Wesnoth, but far simpler 
and with some differences in principles) for which Lua (with Löve, & delegation 
to plain C for critical pathes) is rather close to be an ideal language. 
However, on the scripting side for users, a few conceptual points are 
problematic for me [*]. I would really like to open the door to potential 
programmers, meaning people who may enjoy it.

Thus, metalua. Are there projects using it in a similar spirit?

Denis

[*] I don't intend to launch a discussion on this topic, reason for the 
footnote. Some of those points derive form (old) experiences with potential 
programmers. Here are a few things I'd change. They are mainly about confusion 
in the language of --for me-- semantically different notions:

* equality is "=", assignment is ":" or "::"

* definition (symbol creation) is ":", redefinition (symbol change) is "::"
  (This may also solve the 'global' issue in many cases: one could not change 
_G.x by inattention.)

* composite data (record, object, tuple) is {...}, collection data (mainly 
sequence) is []

* every structured data type has a standard 'tostring'

* maybe no complex expression with precedence (every subexp is grouped in (...))

* One point probably unsolvable is the confusion between genuine function 
(computes a result) and action
  (performs an effect). Anyway, the use of the "return channel" to signal 
errors is well established and well
  done in Lua, so...

* Ideally, I'd also love a different model for variable strings, à la Cobra, where
	"Hello [n] times, [username]!"
  means
	string.format("Hello %d times, %s!", n, username)
  but this gets complicated when mixing user and programmer feedback (for 
debug, testing, maintenance),
  as ideal default formats are different (eg for programmer differentiating 132 
& "132").

* Finally, only one syntax for function defs, namely like other defs:
	f = function (p) ... end
  Don't know about 'methods'.

[Please, if you like to talk of such things, do it off-list.]