Re: The LuaVM implemented in languages other than C

[Fabio Mascarenhas <mascarenhas@...>]

Hi, Anthony,

On Fri, Sep 25, 2009 at 8:38 PM, Anthony Fairchild
<fairchild.anthony@gmail.com> wrote:
> Hello All,
>
> I've been playing around with the idea of implementing a Lisp-like language
> that targets the LuaVM.   The reasons why I chose the Lua VM are 1) It seems
> to be faster than several other VMs and 2) The VM has a very minimalistic
> approach, which makes it very easy to implement.   I want my language to run
> on several platforms that do not support C code, including rich web clients
> like Flash and Silverlight and game development environments like XNA.   I
> really like the idea of a language being built up from a small core which
> can be easily implemented anywhere it is not supported.
>
> I have started a VM implementation in C#, and it passes many lua unit tests
> at this point.  I can compile lua files using luac and run them in both
> Silverlight and XNA.   I have really only spent a couple of days doing this
> and I'm surprised at how straightforward this is.  Setting my Lisp language
> idea aside, I was wondering if this VM might be of any value to others, as
> an alternative way to run Lua code in .NET?  I see there is LuaInterface but
> that doesnt seem to support my requirements because it is a bridge to Lua's
> C VM.
>

The core of the VM itself is very straightforward, and the binary Lua
bytecode format is very easy to parse. And the source of the
interpreter is such a joy to read. :-) I am curious on how much of the
support code, like the implementation of tables, have you already
implemented; have you done a C# port of the C implementation (like I
did for Lua tables) or are you just using a CLR hashtable?

You should be able to reuse several parts of LuaInterface's code if
you wish to let Lua code running in your interpreter access other
parts of the CLR.

Most of the work (not hard, but a quite a lot of work) in doing a Lua
interpreter in another language is in porting the "extended" standard
library, which kind of includes third-party C libraries like
LuaSocket, LuaFileSystem, LPEG etc.

It won't definitely be as fast as the native Lua interpreter, but I
guess that goes without saying. :-) Should be enough for a lot of
uses, though, as there are people using interpreted Lua in J2ME in
much more constrained environments than an XBox 360. Straightforward
compilation of Lua code to the CLR (using the same optimizations for
tables that Lua has) is about as fast as the Lua interpreter, if you
are curious.

--
Fabio Mascarenhas, Lablua
http://www.lua.inf.puc-rio.br