
A Lua interpreter written in C# - chx
http://www.moonsharp.org/
======
Syneh
Looks nice. What I miss from most libraries that let you use a language within
a language, is the ability to blacklist the whole standard library and then
whitelist specific parts of it. Does this support that?

~~~
munificent
It's probably less needed here since Lua's standard library is already pretty
lean.

------
Udo
I like the iterator metamethod, I think I'll borrow that for myself.

It's questionable whether labels/goto are needed at all (Lua didn't have them
until 5.2), in my opinion the language could do very well without.

Coroutines would be nice though.

~~~
sklogic
Labels and gotos are absolutely essential for any decent meta-language.
Although this is only a Lua implementation, without any MetaLua support yet,
but it can probably change, so they'd better provide goto as well by then.

~~~
Udo
What a strange objection. I don't see any reference in the Moon# docs pointing
towards any inclination to implement a meta language. I don't believe MetaLua
support is the end goal here, it's more about providing a decent scripting
language that runs in your C# app.

I don't think everybody agrees that the whole point of Lua is to play host to
MetaLua.

~~~
sklogic
Even without MetaLua, Lua itself may be used as a target language for some
higher level DSL, and this is where goto is essential. Original Lua provides
goto for a reason.

~~~
Udo
Again, I don't think being a target for a higher level DSL is the motivation
for this project.

But let's talk about content instead: what are, in your opinion, the essential
uses of goto in a language that has strong functional features and coroutines?

~~~
sklogic
This project seems to be faithfully implementing Lua, as it is. Apparently,
for the same range of uses as for the original Lua. Which includes DSLs and
all that.

As for the goto being essential: first, FSMs. They cannot be implemented more
naturally and efficiently with anything else. Huge switch can be costly.
Secondly, higher level DSLs may need goto to represent features not directly
available in the host language structural elements. For example, translating a
PEG parser efficiently is very easy if you can goto to the current block exit
without going through a long 'if' ladder, and since blocks are nested, it
cannot be substituted with a return.

~~~
Udo
_> FSMs. They cannot be implemented more naturally and efficiently with
anything else._

It depends a bit on what your motivation for using a Lua interpreter embedded
into the .NET environment is. Instinctively, it wouldn't be my choice for
things that need to be exceedingly fast. But let's say you do want to
implement an FSM in this context where performance isn't critical. States and
state transitions could very well be expressed by functions instead of code
blocks, and there are implementations in the wild that do this.

 _> Huge switch can be costly._

Goto doesn't really help alleviate the cost of chaining if statements either
(which is what Lua forces you to do in the absence of a switch statement). But
if it's critical, you could build dispatch tables with pure Lua tables to
mirror a static switch statement.

If you're concerned about processor cache though, I don't think interpreted
Lua on top of .NET is the right choice to base an FSM of to begin with.

 _> DSLs may need goto to represent features not directly available in the
host language structural elements_

True, but it depends a bit on the paradigms chosen to implement the necessary
transformations. It's correct though that goto statements provide you with a
very intuitive way to shape control flow in the absence of corresponding
features in the host language. If that facility is missing, you lose the
option of translating your canonical C-based algorithms faithfully into Lua
code. Whether that's a bad thing is a matter of debate.

For me it comes down to the consideration of using the right tool for the
appropriate job, which was the context of my original comment. If you're
building a language that needs to satisfy every possible use case efficiently
(both in respect to execution and programmer effort), you're just screwed.
This is especially true for interpreted languages, and extraordinarily so if
they're supposed to host higher level interpreted languages on top.

~~~
sklogic
Well, it's not only about efficiency. It's also about semantics. Goto
semantics is cleaner in the cases I'm talking about, and any workaround
(tables of functions, etc.) would be just clumsy and less maintainable. I
know, there is a knee-jerk reaction on goto that it supposedly always leads to
unmaintainable spagetty, but in fact it often helps to write a cleaner code,
especially if it is not used directly, but generated by a higher level
compiler for the high level language entities (FSMs, nested parsing blocks,
etc.)

And Lua is not that bad at all for an interpreted language, it's fairly fast
(especially the LuaJIT implementation), and it is possible to implement a nice
compiled or semi-compiled Lua backend on top of .net. So it is reasonable to
expect that it can serve as a backend for compiling higher level languages, as
well as for the usual simple scripting.

------
eropple
This is pretty rad. I had hopes for Kopilua and Aluminum Lua, but neither
panned out. If I go back to Unity, I'm gonna use this. Thanks for open-
sourcing it!

For now, I actually use CSharpCodeProvider and compile C# as "scripts" during
game start (and cache it for future use), searching across attributes to find
the right item. When deploying to platforms that don't have CSharpCodeProvider
(Xamarin.iOS, for example), I can precompile the scripts, pack the assemblies,
and the fallback is trivial.

------
jmspring
I was looking at doing this awhile back by improving Kopilua (which had looked
to be abandoned, and now seems to have a little bit of activity again):

[https://github.com/NLua/KopiLua](https://github.com/NLua/KopiLua)

However, other projects came up.

My interest was in a c# implementation of Lua where scripts would run in a
cross-platform manner. I'm not sure the "addititions"/"modifications" in Moon#
will meet those needs. If I return to said project, I will definitely take a
look.

------
7007
In what ways does this differ from
[https://github.com/chkn/AluminumLua](https://github.com/chkn/AluminumLua) ?

~~~
eropple
AluminumLua isn't nearly complete and isn't a pure interpreter. It can't run
on Xamarin.iOS, for example.

------
Toenex
Something similar exists in the Java world too.

[http://luaj.org/luaj/README.html](http://luaj.org/luaj/README.html)

------
cevaris
For a second I thought this said C# interpreter written in Lua....but yeah..

------
jtwebman
What no labels and Gotos!!! ---joking :)

