3 ms·

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 sup

by Udo 12y ago

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 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      > 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.
      - pjmlp 12y ago
        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.
      - sklogic 12y ago
        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.
    - munificent 12y ago
      > 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 http://www.lua.org/pil/6.3.html

by Udo 12y ago

sklogic 12y ago

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 12y ago
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 12y ago
  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 12y ago
    > 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.
    - pjmlp 12y ago
      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.
    - sklogic 12y ago
      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.
  - munificent 12y ago
    > 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 http://www.lua.org/pil/6.3.html