C# and Lua

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

C# and Lua

Marco Kögler
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.


Reply | Threaded
Open this post in threaded view
|

RE: C# and Lua

John Passaniti-4
While I can't comment on using the C# interop mechanisms to work with a
C-language Lua, I was very interested to read this:

> 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.

It's probably old news for others here, but I never saw any sort of
announcement that a Lua.NET was in the works.  So I looked in Google and
found this:

http://www.tecgraf.puc-rio.br/~rcerq/luadotnet/

Which also leads to this:

http://research.microsoft.com/collaboration/university/europe/rotor/default.
asp


I look forward to a Lua.NET.  I especially look forward to a Lua implemented
in C#.  Interesting that Microsoft Research is sponsoring this.




Reply | Threaded
Open this post in threaded view
|

RE: C# and Lua

Michael
In reply to this post by Marco Kögler

As far as I know, there's been little success implementing scripting languages in .NET. The problem is that most scripting languages are dynamically typed, and the .NET Runtime is statically typed. The Python.NET guys experimented with a variety of approaches--such as emiting code on the fly--but none worked very well. (I don't know the current status of Python.NET.)

Of course, it's still possible to implement an interpreter on top of .NET, and write glue between the two layers. That, however, isn't quite the same as producing Lua.NET--which has JIT-compiled code, debugging support, etc.



"John Passaniti" <[hidden email]>
Sent by: [hidden email]

01/05/2003 10:55 PM
Please respond to lua-l

       
        To:        Multiple recipients of list <[hidden email]>
        cc:        
        Subject:        RE: C# and Lua



While I can't comment on using the C# interop mechanisms to work with a
C-language Lua, I was very interested to read this:

> 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.

It's probably old news for others here, but I never saw any sort of
announcement that a Lua.NET was in the works.  So I looked in Google and
found this:

http://www.tecgraf.puc-rio.br/~rcerq/luadotnet/

Which also leads to this:

http://research.microsoft.com/collaboration/university/europe/rotor/default.
asp


I look forward to a Lua.NET.  I especially look forward to a Lua implemented
in C#.  Interesting that Microsoft Research is sponsoring this.





Reply | Threaded
Open this post in threaded view
|

RE: C# and Lua

Sean Middleditch
It really shouldn't be much different than writing Lua in C, no?  I
mean, you could have a .NET type/class for a "Lua Value", which used the
native String/int/float/array/etc. types where appropriate.  It could
allow dynamic changing - assign an array type to the type (value.assign
(array)) and the class stores the array and marks itself as an array
type.  Assing a string to the same variable/member/etc. (value.assign
("a string"))) and it would store the string, and mark itself as a
string type.

The method could be overloaded to react differently based on the type. 
For example the + operator could look at the types involved - if
strings, do concatenation; if numbers, just add; if tables, call a
method in the table, and so on.

It won't be able to optimize as well (for example, know to just call
string concatenation at compile time, versus having to check types on
run-time) but it would still work, I would think.

Or am I missing some important fact here?  (as usual) ^,^

On Mon, 2003-01-06 at 12:19, [hidden email] wrote:
> As far as I know, there's been little success implementing scripting
> languages in .NET. The problem is that most scripting languages are
> dynamically typed, and the .NET Runtime is statically typed. The
> Python.NET guys experimented with a variety of approaches--such as
> emiting code on the fly--but none worked very well. (I don't know the
> current status of Python.NET.)
> 
> Of course, it's still possible to implement an interpreter on top of
> .NET, and write glue between the two layers. That, however, isn't
> quite the same as producing Lua.NET--which has JIT-compiled code,
> debugging support, etc.
> 
> 
> 
> 
> "John Passaniti"
> <[hidden email]>
> Sent by:
> [hidden email]
> 
> 01/05/2003 10:55 PM
> Please respond to lua-l
>         
>         To:      
> Multiple recipients of
> list
> <[hidden email]>
>         cc:        
>         Subject:      
> RE: C# and Lua
> 
> 
> While I can't comment on using the C# interop mechanisms to work with
> a
> C-language Lua, I was very interested to read this:
> 
> > 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.
> 
> It's probably old news for others here, but I never saw any sort of
> announcement that a Lua.NET was in the works.  So I looked in Google
> and
> found this:
> 
> http://www.tecgraf.puc-rio.br/~rcerq/luadotnet/
> 
> Which also leads to this:
> 
> http://research.microsoft.com/collaboration/university/europe/rotor/default.
> asp
> 
> 
> I look forward to a Lua.NET.  I especially look forward to a Lua
> implemented
> in C#.  Interesting that Microsoft Research is sponsoring this.
> 
> 
> 
-- 
Sean Middleditch <[hidden email]>
AwesomePlay Productions, Inc.


Reply | Threaded
Open this post in threaded view
|

RE: C# and Lua

Michael
In reply to this post by Marco Kögler

It depends on what you're trying to do. If you're trying to build an interpreter that runs in .NET, then yes that's of course possible. And it's possible to write some glue that allows you to call to and from that interpreter (as you can call to and from C in Lua).

When .NET was being brought to life, though, the promise was for rather more than that. The promise was that you could use a single back-end--with its compiler, debugger, profiler, and class libraries--with a varierty of languages. Microsoft either paid for or promoted efforts to bring a variety of langauges to .NET to show that this was possible.

As it turns out, it was indeed possible for statically-typed languages, but not for dynamically-typed languages. Although my knowledge may be out of date, last I heard there was no truly successful (ie, usable) port of a dynamically-typed language to the .NET runtime (as a first-class language).

The report from the Python crew is available here:

        http://www.activestate.com/Corporate/Initiatives/NET/Python_for_.NET_whitepaper.pdf

Here are two quick excerpts:

Python code does not have type declarations. However, all Python objects have a distinct type, so Python
is not a typeless language. For example, if we consider the two Python statements:

        a = "hello"
        a = 7

Although the Python variable a has not been declared, after the first statement it references a Python
string object, and after the second it references a Python integer object. At any point in time, the variable
has a specific type.

As a result of this, the compiler is rarely able to generate efficient code. The compiler makes no attempt
to track variable assignments and types, so always generates code for the general case. Thus, simple
arithmetic operations take many orders of magnitude more Intermediate Language instructions (including
calls into the Python for .NET runtime) than would be required if the types of the variables were known.

There are two general approaches to this - type inference and type declarations. Type interference would
involve the compiler tracking assignments and the type of objects. Although good results would be
possible using local analysis, the dynamic nature of Python, and the modular compilation unit would
prevent this working completely effectively. Type declarations would involve explicit declarations or
other hints being added by the user. However, Python does not define syntax for these features.

and:

Due to Python's dynamic nature, there are some Python features that are difficult to map into .NET
semantics. A simple example is the ability for a Python object to add attributes at runtime - although no
declaration or other reference to the attribute can be seen by source code analysis, reference to the
attribute will succeed at runtime. Python provides many other ways to change object behavior at runtime
that are not captured by .NET.

To support this capability, the compiler will often emit special symbols or code specific to Python. At
runtime, if these features are found they are used, and thus Python can take advantage of these features.
This allows Python code compiled in a separate compilation unit (that is, it exists in a separate assembly)
to still provide these dynamic Python semantics when the caller is Python.

This dynamic capability is analogous to IDispatch support in COM - the ability for a language to
dynamically determine or expose an object model at runtime. .NET is focused much more towards
compile time determination of these attributes, in a clear drive for speed. However, the very nature of
Python and scripting languages in general is that their users have made a conscious decision to trade
execution speed for these runtime features - although possibly not as much execution speed as Python for
.NET is currently costing them.

It is clear such dynamic features may preclude certain other .NET features - for example, the performance
penalty associated with allowing dynamically obtained methods to be used as virtual methods may mean
they are not supported as virtual. However, there is still enough utility in the feature overlap that would
make this a useful, but optional .NET addition.

It should also be noted that there are many languages with dynamic features comparable to Python.
However, with Python and every other such language needing to invent its own dynamic solution, these
languages are not able to share such features, even when it would make sense to be able to do so.
Formalization of these features in .NET would allow multiple dynamic languages to interoperate in a
natural manner.



Sean Middleditch <[hidden email]>
Sent by: [hidden email]

01/06/2003 12:48 PM
Please respond to lua-l

       
        To:        Multiple recipients of list <[hidden email]>
        cc:        
        Subject:        RE: C# and Lua



It really shouldn't be much different than writing Lua in C, no?  I
mean, you could have a .NET type/class for a "Lua Value", which used the
native String/int/float/array/etc. types where appropriate.  It could
allow dynamic changing - assign an array type to the type (value.assign
(array)) and the class stores the array and marks itself as an array
type.  Assing a string to the same variable/member/etc. (value.assign
("a string"))) and it would store the string, and mark itself as a
string type.

The method could be overloaded to react differently based on the type.
For example the + operator could look at the types involved - if
strings, do concatenation; if numbers, just add; if tables, call a
method in the table, and so on.

It won't be able to optimize as well (for example, know to just call
string concatenation at compile time, versus having to check types on
run-time) but it would still work, I would think.

Or am I missing some important fact here?  (as usual) ^,^

On Mon, 2003-01-06 at 12:19, [hidden email] wrote:
> As far as I know, there's been little success implementing scripting
> languages in .NET. The problem is that most scripting languages are
> dynamically typed, and the .NET Runtime is statically typed. The
> Python.NET guys experimented with a variety of approaches--such as
> emiting code on the fly--but none worked very well. (I don't know the
> current status of Python.NET.)
>
> Of course, it's still possible to implement an interpreter on top of
> .NET, and write glue between the two layers. That, however, isn't
> quite the same as producing Lua.NET--which has JIT-compiled code,
> debugging support, etc.
>
>
>
>
> "John Passaniti"
> <[hidden email]>
> Sent by:
> [hidden email]
>
> 01/05/2003 10:55 PM
> Please respond to lua-l
>        
>         To:      
> Multiple recipients of
> list
> <[hidden email]>
>         cc:        
>         Subject:      
> RE: C# and Lua
>
>
> While I can't comment on using the C# interop mechanisms to work with
> a
> C-language Lua, I was very interested to read this:
>
> > 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.
>
> It's probably old news for others here, but I never saw any sort of
> announcement that a Lua.NET was in the works.  So I looked in Google
> and
> found this:
>
> http://www.tecgraf.puc-rio.br/~rcerq/luadotnet/
>
> Which also leads to this:
>
> http://research.microsoft.com/collaboration/university/europe/rotor/default.
> asp
>
>
> I look forward to a Lua.NET.  I especially look forward to a Lua
> implemented
> in C#.  Interesting that Microsoft Research is sponsoring this.
>
>
>
--
Sean Middleditch <[hidden email]>
AwesomePlay Productions, Inc.



Reply | Threaded
Open this post in threaded view
|

Re: C# and Lua

Marco Kögler-2
[hidden email] wrote:
It depends on what you're trying to do. If you're trying to build an interpreter that runs in .NET, then yes that's of course possible. And it's possible to write some glue that allows you to call to and from that interpreter (as you can call to and from C in Lua).

This is exactly, what I'm trying to do. I don't want to port Lua to .NET ... just be able to call .NET code from Lua. The calling convention which Lua (by default) uses for callbacks poses a problem, though, as it prevents me from passing delegates to Lua ... which is the only method I know of how to call back a C# function. So, I wanted to mention this to the Lua community ... I can easily compile a Lua DLL, which allows the passing of delegates by changing the calling convention to stdcall.

Somebody mentioned the existance of LuaPlus per private mail. It has a managed wrapper of their enhanced C++ Lua interface, but I just wanted the bare bones Lua API (for starters).

Thanks,
Marco


Reply | Threaded
Open this post in threaded view
|

Re: C# and Lua

Markus Fritsche
In reply to this post by Michael
[hidden email] wrote:

When .NET was being brought to life, though, the promise was for rather more than that. The promise was that you could use a single back-end--with its compiler, debugger, profiler, and class libraries--with a varierty of languages. Microsoft either paid for or promoted efforts to bring a variety of langauges to .NET to show that this was possible.

.NET Supports only languages that are are subset or equivalent to C# (or languages that are cut down to be a C# equivalent). I'm not sure if this multi language thing and it's few advantages will outweight the big disadvantages.

Regards, Markus

--
http://reauktion.de/archer/


Reply | Threaded
Open this post in threaded view
|

Re: C# and Lua

Marco Kögler
In reply to this post by Marco Kögler
Hi!

Hmm, I'm eternally stupid ... I just caught the stdcall.lua script in the Lua distribution (under etc/) ... it does the changes I've proposed ... oh well. Sorry for bothering everybody.

-Marco


Reply | Threaded
Open this post in threaded view
|

Re: C# and Lua

Michael
In reply to this post by Marco Kögler
Yes, that's the approach that Perl.NET takes. You could look at what they
did as a potential model for wiring things up.



                                                                                                                                                
                      Marco Kögler                                                                                                              
                      <koegler@uni-koblen        To:       Multiple recipients of list <[hidden email]>                               
                      z.de>                      cc:                                                                                            
                      Sent by:                   Subject:  Re: C# and Lua                                                                       
                      owner-lua-l@tecgraf                                                                                                       
                      .puc-rio.br                                                                                                               
                                                                                                                                                
                                                                                                                                                
                      01/06/2003 02:08 PM                                                                                                       
                      Please respond to                                                                                                         
                      lua-l                                                                                                                     
                                                                                                                                                
                                                                                                                                                




[hidden email] wrote:
> It depends on what you're trying to do. If you're trying to build an
> interpreter that runs in .NET, then yes that's of course possible. And
> it's possible to write some glue that allows you to call to and from that

> interpreter (as you can call to and from C in Lua).

This is exactly, what I'm trying to do. I don't want to port Lua to .NET
... just be able to call .NET code from Lua.  The calling convention
which Lua (by default) uses for callbacks poses a problem, though, as it
prevents me from passing delegates to Lua ... which is the only method I
know of how to call back a C# function. So, I wanted to mention this to
the Lua community ... I can easily compile a Lua DLL, which allows the
passing of delegates by changing the calling convention to stdcall.

Somebody mentioned the existance of LuaPlus per private mail. It has a
managed wrapper of their enhanced C++ Lua interface, but I just wanted
the bare bones Lua API (for starters).

Thanks,
Marco