lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

We are working on a project where Lua is the middle-wear that binds to
other languages. We do quite a bit of our application programming in
C# and our first binding to it.

Our current workflow is Lua 5.3 -> Managed C++ -> C#, but as my
colleague put it today, "We are interested in binding our library to
C#, not all of Lua to C#." Therefore, we are looking around.

It looks to me as though nLua[1] (formerly LuaInterface) is the
leading way to use Lua and C#. Many of the examples show Lua in the
scripting role, but it appears that it may work well in both

Some considerations:

1: We need Lua to be able to load C and Lua libraries with require.
2: We also need to be able to call delegates (and most likely other
objects) from Lua, but mostly C# is calling into Lua objects (I'm
using penlight's objects).
3: We use Lua 5.3
4: C#/Windows is not the only target language/platform.

Does anyone have experience with this or something similar? I'm
curious if anyone has tried using the "unsafe" keyword and just bound
Lua to C#, without an extensive wrapper. I'm also curious about any

I didn't see any 5.3 issues open on github, so I assume that it is not
on their map. I don't want to loose 64bit integers, but I am also
unsure of where the greatest uncertainty / pain lies, so I don't know
anything about whether forking the project to work with 5.3 is better
or dropping 5.3 is better... That question is better question for the
authors of the project, however. I mention it here, in case experience
has already had its say with someone here.

A JSON very-high-level binding is still being considered, but:
 - The binding would be dead simple.
 - Other languages (especially Javascript) would use this, as well.
 - This is pretty much done, but using it in C# is not *that* easy. It
feels a lot like writing the whole library again.
 - we think that this will lead to too much maintenance.
 - we'd have to re-implement the Lua object model that we've already
made in C#. (We may end up having to do that with nLua, too)
 - Increased probability of low performance, or at least limited
future options.
 - A proper integration would increase the possibility of extending
our library with C# delegates (uber-function pointers).