On Fri, Sep 25, 2009 at 8:30 PM, Fabio Mascarenhas
<mascarenhas@acm.org> wrote:
Hi, Anthony,
On Fri, Sep 25, 2009 at 8:38 PM, Anthony Fairchild
> 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. :-)
The lua source is very well written. Some of the best C code I've seen in a while. Even the heavily optimized parts are easy 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?
I was planning on only implementing the standard library, or at least the parts I need, like i/o. I have not implemented the Lua-style tables. Just using hashtables but I do support metatables. This is really a placeholder tho for the real thing. I'll have to take a look at your Lua tables implementation.
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.
I'll take a look at the LuaInterface code. At the moment the library functions are implemented using a simple delegate
Func<TValue[], TValue[]> _function;
So the print library function looks like this:
public static TValue[] Print(TValue[] parms)
{
// TODO: probably not a proper print, but it works for now!
Console.Out.WriteLine(String.Join("\t", parms.Select(o => o.ToString()).ToArray()));
return null;
}
I'm sure there are better ways to do this, like using reflection.
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.
I'm not that concerned about the extended libraries. For example, I have a sprite library that works in both Silverlight and XNA. I would just write my own lua library around this for doing the rendering and then write the game logic in Lua. I would implement libraries like this as needed.
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.
I am less concerned about speed and more interested in portability. Maybe I am a little too optimistic about the speed but I can always implement the bottlenecks in the native language. A LuaVM byte code to CIL is not a bad idea either and can be done if speed ever becomes a real issue.
Thanks for your comments!
--
Fabio Mascarenhas, Lablua
http://www.lua.inf.puc-rio.br
