A Lua interpreter written in C#
moonsharp.org
A Lua interpreter written in C#
1–10 of 20 posts
Re: A Lua interpreter written in C#
#2I 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.
Re: A Lua interpreter written in C#
#3I 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.
Re: A Lua interpreter written in C#
#4Looks 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?
Re: A Lua interpreter written in C#
#5Something similar exists in the Java world too.
Re: A Lua interpreter written in C#
#6I 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.
Re: A Lua interpreter written in C#
#7Earlier quoted context omitted.
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.
Re: A Lua interpreter written in C#
#8Earlier quoted context omitted.
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?
Re: A Lua interpreter written in C#
#9Earlier quoted context omitted.
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.
Re: A Lua interpreter written in C#
#10Earlier quoted context omitted.
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…
> 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.