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:
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 <elanthis@awesomeplay.com> Sent by: owner-lua-l@tecgraf.puc-rio.br
01/06/2003 12:48 PM
Please respond to lua-l
To: Multiple recipients of list <lua-l@tecgraf.puc-rio.br>
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, MichaelL@frogware.com 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"
> <jpass@rochester.rr.com>
> Sent by:
> owner-lua-l@tecgraf.puc-rio.br
>
> 01/05/2003 10:55 PM
> Please respond to lua-l
>
> To:
> Multiple recipients of
> list
> <lua-l@tecgraf.puc-rio.br>
> 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 <elanthis@awesomeplay.com>
AwesomePlay Productions, Inc.
