Are there any production-quality cross-language compilers that support all the subtle semantics of the source language correctly? (I'm excluding C as a target language, which I know is often used as an output format for production-quality compilers).
I feel like I always see projects like this that have just started out, and provide no discussion of the difficult edge cases and how they will be supported. Correctly implementing a programming language is a really hard problem. Programming languages have tons and tons of subtle edge cases, like what happens if you add two objects of different types (think about the "wat?" talk: http://www.youtube.com/watch?v=kXEgk1Hdze0). If you don't get all these semantics correct, then your implementation won't be compatible with code written on other implementations.
Charles Nutter has obviously done a lot of work implementing Ruby in the past so is surely aware of all of this. I just wonder, when I see a project like this, what the ultimate plan is. Is it:
- the project is new and incomplete, but we plan to work on it until it correctly supports all semantics of the source language, even if the generated code gets uglier and more complicated as a result
- the project is new and incomplete, and we'll add support for more stuff but not get too worried about every last quirk of the source language, especially if it makes the generated code get too complicated
- the project is just an interesting hack, a fun side project, an experimental prototype or proof-of-concept, etc, and you shouldn't expect much compatibility.
I would say it is the second goal right now. Implementing JRuby and Mirah taught me a lot about features of Ruby that can map directly to Java/JVM, and I feel like this can be a very useful, functional subset of Ruby. Because this is a "compile the world" approach, things like evaluation probably will never be supported. But because it can generate the whole system, things like methods_missing, send, and respond_to? are all doable (and I just pushed m_m support a few hours ago). That opens up possibilities that are hard to achieve in typical statically typed languages without requiring any complicated dynamic dispatch system.
Honestly I feel like the biggest feature of both Mirah and RubyFlux are their ability to produce binaries that have no external dependencies. You only pay for what you use, and in both cases you,really just doing normal JVM calls under the covers. What Mirah achieves through static typing, RubyFlux achieves by generating all method names as stubs on a base class.
As others have pointed out...it is also just a fun experiment :-) But that is how both JRuby and Mirah started out too.
I feel like I always see projects like this that have just started out, and provide no discussion of the difficult edge cases and how they will be supported. Correctly implementing a programming language is a really hard problem. Programming languages have tons and tons of subtle edge cases, like what happens if you add two objects of different types (think about the "wat?" talk: http://www.youtube.com/watch?v=kXEgk1Hdze0). If you don't get all these semantics correct, then your implementation won't be compatible with code written on other implementations.
Charles Nutter has obviously done a lot of work implementing Ruby in the past so is surely aware of all of this. I just wonder, when I see a project like this, what the ultimate plan is. Is it:
- the project is new and incomplete, but we plan to work on it until it correctly supports all semantics of the source language, even if the generated code gets uglier and more complicated as a result
- the project is new and incomplete, and we'll add support for more stuff but not get too worried about every last quirk of the source language, especially if it makes the generated code get too complicated
- the project is just an interesting hack, a fun side project, an experimental prototype or proof-of-concept, etc, and you shouldn't expect much compatibility.