2 ms·

I disagree :) A transcompiler would have to be able to produce pretty much 1:1 mapping between one language and another. In this case, it would have to be emit

by headius 14y ago

I disagree :) A transcompiler would have to be able to produce pretty much 1:1 mapping between one language and another. In this case, it would have to be emitting the equivalent of dynamic calls, which isn't really possible on the JVM (other than through invokedynamic, which does work very well). Instead, this is using a static view of the world to produce the resulting code...assuming only the method names it sees statically at compile time will ever exist, and generating a static picture of that world. Hell...it's actually turning all dynamic dispatch into static dispatch. How could a transcompiler possibly do that? Also...performance gains being offset by the size of the JVM? I don't understand this at all.

kintamanimatt 14y ago
No, what you've produced is a transcompiler which takes the source code from one language and converts it to source code in another language at the same high level. The fact there isn't a 1:1 mapping between the source language and the destination language isn't relevant. Strangely, it doesn't appear the Dragon Book mentions transcompilation, but Wikipedia has a decent definition: https://en.wikipedia.org/wiki/Transcompiler https://en.wikipedia.org/wiki/Transcompiler This isn't static compilation in any sense of the definition as you're not producing a low-level language, i.e. assembly or machine code. Ultimately the JVM will do some combination of static and JIT compilation, but your code isn't doing this. In no way am I deriding your effort, you've just got your definitions mixed up. The JVM tends to run in a relatively large memory footprint compared to the MRI, although the JVM will execute faster when it's warmed up. The JVM isn't known for being frugal when it comes to memory usage. For long running processes, your transcompiler could be very useful.

by headius 14y ago

kintamanimatt 14y ago

No, what you've produced is a transcompiler which takes the source code from one language and converts it to source code in another language at the same high level. The fact there isn't a 1:1 mapping between the source language and the destination language isn't relevant. Strangely, it doesn't appear the Dragon Book mentions transcompilation, but Wikipedia has a decent definition: https://en.wikipedia.org/wiki/Transcompiler https://en.wikipedia.org/wiki/Transcompiler This isn't static compilation in any sense of the definition as you're not producing a low-level language, i.e. assembly or machine code. Ultimately the JVM will do some combination of static and JIT compilation, but your code isn't doing this. In no way am I deriding your effort, you've just got your definitions mixed up. The JVM tends to run in a relatively large memory footprint compared to the MRI, although the JVM will execute faster when it's warmed up. The JVM isn't known for being frugal when it comes to memory usage. For long running processes, your transcompiler could be very useful.