C# and Lua

[Marco Kögler <marco.koegler@...>]

Hi!

I'm new to this list, so beware :)

I've been experimenting with getting Lua 5.0-beta to work in C#. I used 
the standard C# Interop mechanisms to import all the lua_-functions from 
a DLL-version I created. The only problem I had were when I tried to 
access a C#-Function from a Lua script. The Interop-mechanism normally 
allows to pass C# Delegates (C# equivalent to function pointers) to 
other (native) functions, and they can treat it like a regular function 
pointer. The problem with Lua is, that Lua expects the cdecl-calling 
convention and delegates are marshalled as stdcall. This behavior can't 
be changed on the C# side, so I was wondering whether it would break too 
much code to have lua_CFunction use the stdcall calling convention ... 
maybe at least as something which can be changed at compile-time via a 
#define (LUA_CALLBACK_CONVENTION). I know that this might make existing 
binary packages incompatible and it also requires the user to tag his 
function wrappers with stdcall (or a #define symbol).

I mean, for me it is OK to have a separate version of Lua ... I'll 
probably wrap the entire Lua code into a managed C++ DLL. But, I just 
wanted to make the Lua community aware, that they could support C# (and 
possibly other .NET languages) very easily by changing the calling 
convention on lua_CFunction.

If this change won't make it into the Lua code-base I might have the 
time to provide a .NET Assembly if there is interest. I was thinking of 
wrapping the lua_State into a class 'State' in the Lua namespace. So, 
something like...

lua_State *L = lua_open();
...
lua_gettop(L);

would become

Lua.State L = Lua.Open();
...
L.GetTop();

I would also provide a 'compatability layer' which will look as much as 
possible like the standard C API and just lives in the Lua namespace. 
Sorta like (note, only difference would be the absence of pointers):

using Lua.C_API;

lua_State L = lua_open();
...
lua_gettop(L);

What do you guys think? BTW, if somebody has some pointers to C++ 
wrappers for Lua, then I might be able to look at those as well ... just 
to see how they approached this design-wise.

-Marco
PS: I'm aware of the fact, that there'll be a Lua.NET down the road 
(I've seen the project page), but I need Lua now ... not in (many?) months.