3 ms·

While it seems that their transpiler supports just simple JSON-like expressions with support for constructors for non-native literals (like big integers) and I

by krcz 7y ago

While it seems that their transpiler supports just simple JSON-like expressions with support for constructors for non-native literals (like big integers) and I don't think it could generalize into arbitrary code translation, I still appreciate the work they've done. Transpilation between arbitrary high level languages is a very hard task and I doubt anyone can achieve good solution for that anytime soon. I have a different solution in mind: designing a language specifically for transpilation, so that it could be used to generate high quality, readable code for various programming languages (I call it "idiomatic translation"). I've recently started exploring that topic as a part of Zygote project [1]. [1] https://github.com/krcz/zygote https://github.com/krcz/zygote

OJFord 7y ago
Is that so different? The natural next step is implementing the reverse, other languages to yours, and then suddenly yours is an intermediate language that can be used to go other lang to other lang.
- krcz 7y ago
  That might not be easy, for the same reason you can easily transform vector graphics into raster one but not the other way around or output of decompilers doesn't look nice: you are losing information during the translation process. You can easily transpile TypeScript to JavaScript, but that's not true for the reverse process.
  - ptx 7y ago
    The reverse process should be easy! Since TypeScript is a superset of JavaScript, transpilation is an identity transform. :)
swsieber 7y ago
You should check out Haxe. - it compiles to 10 source level languages and a couple of VMs. https://haxe.org/ https://haxe.org/
- krcz 7y ago
  Thank you, Haxe definitely has its place on my list of things to check. What worries me however is that there are no examples of output code on their webpage.
  - swsieber 7y ago
    True. I don't think the output will be particularly pretty, and it does assume the presence of its own stdlib. But hopefully it's still fun to see how exactly they do things under the hood.
  - haxiomic 7y ago
    The output is pretty slim, it's one of the reasons I prefer using haxe over TypeScript when targeting the web – haxe has better dead-code-elimination so output js tends to be smaller and include a greater level of optimisation – check out this example to see what I mean https://try.haxe.org/#4f46D https://try.haxe.org/#4f46D
- dkersten 7y ago
  The targets Haxe compiles to are all rather similar (object oriented mutable-state imperative VM's). While that's cool and interesting, its far from any language. I imagine adapting it to compiling to something like Haskell may be less than straightforward, at least in a way that produces decent quality/performant Haskell code.
aikah 7y ago
The best solution is to make every language a compile target for a virtual machine or some CLR flavor. Creating yet another "high level" language that compile to all other languages would mean designing something that is the least common denominator between all languages, which is OK for a language that is not supposed to be written by hand, AKA bytecode, it's not OK for a language developers are supposed to write.
- krcz 7y ago
  But in order to make it work you would need all the programs to start using the CLR. It's all of nothing. And if one of languages stops being supported - e.g. not receiving bindings for new libraries - you need to rewrite whole codebase to something different. In case of the "high level" language you just need to transpile it to one of the supported languages and continue development in the output language. > designing something that is the least common denominator between all languages My vision is rather finding some patterns, higher abstractions in various languages: e.g. imperative loop summing squares of all odd elements is semantically similar to filter -> map -> fold functional chain. Building whole language on such patterns will definitely be hard, but I believe it is possible and worth pursuing.

by krcz 7y ago

OJFord 7y ago

Is that so different? The natural next step is implementing the reverse, other languages to yours, and then suddenly yours is an intermediate language that can be used to go other lang to other lang.

krcz 7y ago
That might not be easy, for the same reason you can easily transform vector graphics into raster one but not the other way around or output of decompilers doesn't look nice: you are losing information during the translation process. You can easily transpile TypeScript to JavaScript, but that's not true for the reverse process.
- ptx 7y ago
  The reverse process should be easy! Since TypeScript is a superset of JavaScript, transpilation is an identity transform. :)

swsieber 7y ago

You should check out Haxe. - it compiles to 10 source level languages and a couple of VMs. https://haxe.org/ https://haxe.org/

krcz 7y ago
Thank you, Haxe definitely has its place on my list of things to check. What worries me however is that there are no examples of output code on their webpage.
- swsieber 7y ago
  True. I don't think the output will be particularly pretty, and it does assume the presence of its own stdlib. But hopefully it's still fun to see how exactly they do things under the hood.
- haxiomic 7y ago
  The output is pretty slim, it's one of the reasons I prefer using haxe over TypeScript when targeting the web – haxe has better dead-code-elimination so output js tends to be smaller and include a greater level of optimisation – check out this example to see what I mean https://try.haxe.org/#4f46D https://try.haxe.org/#4f46D
dkersten 7y ago
The targets Haxe compiles to are all rather similar (object oriented mutable-state imperative VM's). While that's cool and interesting, its far from any language. I imagine adapting it to compiling to something like Haskell may be less than straightforward, at least in a way that produces decent quality/performant Haskell code.

aikah 7y ago

The best solution is to make every language a compile target for a virtual machine or some CLR flavor. Creating yet another "high level" language that compile to all other languages would mean designing something that is the least common denominator between all languages, which is OK for a language that is not supposed to be written by hand, AKA bytecode, it's not OK for a language developers are supposed to write.

krcz 7y ago
But in order to make it work you would need all the programs to start using the CLR. It's all of nothing. And if one of languages stops being supported - e.g. not receiving bindings for new libraries - you need to rewrite whole codebase to something different. In case of the "high level" language you just need to transpile it to one of the supported languages and continue development in the output language. > designing something that is the least common denominator between all languages My vision is rather finding some patterns, higher abstractions in various languages: e.g. imperative loop summing squares of all odd elements is semantically similar to filter -> map -> fold functional chain. Building whole language on such patterns will definitely be hard, but I believe it is possible and worth pursuing.