|
David Manura wrote:
On Thu, Nov 13, 2008 at 6:51 PM, Fabien wrote:A more challenging approach would be to try to keep the generated code as structurally similar as possible to the original Lua input. Of course, the more "tricky primitives" you rule out (setfenv, setmetatable, coroutine.*, ...), the easier it is to achieve structural integrity;... A more interesting approach would be a gracefully degrading one: as your program start to introduce usage of trickier primitives, you "degrade" to more faithful but less readable translation schemes.Some observations... [snip] Now, the effort to reimplement Lua in Lua[1] is interesting here. If you want to reimplement Lua in some language X (e.g. JavaScript), it can be sufficient to write a translator that translates code to X from the subset of Lua that the Lua-in-Lua code uses because then you can use that translator to convert Lua-in-Lua to X. [snip]
A rather belated comment... There was a project by a Japanese developer that implemented the VM portion in Lua... not sure if it's listed in the wiki, but it popped up on the list before.
Anyway, regarding Yueliang (ref [1]), it's being hacked on a very casual basis, and a back-end (VM) is unlikely for now because I haven't found an application that is useful enough to apply it to. Effort on Yueliang's front end portions were prompted by LuaSrcDiet. The possibility of Lua on Lua or Lua on JavaScript haven't been as appealing because I have no immediate use for those things for now. I am currently just aiming for a native code generator with copious documentation. Just FYI in case anyone is waiting for progress or anything like that.
[snip] [1] http://yueliang.luaforge.net/ [2] http://lua-users.org/wiki/StringLibraryInLua [3] http://lua-users.org/wiki/LuaInterpreterInLua [4] http://lua-users.org/wiki/LuaToCee [5] http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html [6] http://math2.org/eulermb/pod/EulerMB/Coroutine.html [7] http://code.google.com/p/mochalua/
-- Cheers, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia