A Lua interpreter written in C# | Hacker News Reader

A Lua interpreter written in C#

moonsharp.org

76 pointschx19 comments

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?

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

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.

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.

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.

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.

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?

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.

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

It is all a question of implementation.

I am on mobile, so cannot check easily the current implementation.

However it can be translated into MSIL, make use of the dynamic language runtime or eventually use the upcoming .NET Native infrastructure when it becomes available.

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.

> As for the goto being essential: first, FSMs. They cannot be implemented more naturally and efficiently with anything else.

Lua has proper tail calls, which are the natural way to express FSMs there. Programming in Lua actually uses an FSM as an example when explaining the motivation behind tail calls:

http://www.lua.org/pil/6.3.html

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.

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

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.

In what ways does this differ from https://github.com/chkn/AluminumLua ?

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

Something similar exists in the Java world too.

http://luaj.org/luaj/README.html

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

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

Reply on news.ycombinator.com