Play Home Contribute GitHub Join Us Discourse Staff Members GitHub Contribution Guides Team

“Transpiling” from another language


Despite looking through Aether and CodeCombat’s repository (and associated wikis), I couldn’t find out:

  • what is meant by transpiling;
  • what are the interfaces to provide code to Aether ?
    Indeed, “[being] able to get the player’s code from the source language into the first step of Aether’s transpilation pipeline” [0] isn’t exactly helpful.

The motivation here is that I would love to be able to use js_of_ocaml, an OCaml to JS compiler (which has been used to run the OCaml REPL in the browser) and enable people to play CodeCombat with OCaml code.

Bourne Again Shell a.k.a. Bash

Transpiling” is trans-compiling: basically compiling, but maintaining the same level of abstraction (like CoffeeScript to JavaScript) rather than going to a more specific level (C to machine language).

As far as extending Aether to handle more languages: yes, let’s! deepak1556 has been working on adding CoffeeScript to get some of the language selection pipeline out of the way, since that should be the simplest language to add. For Aether’s machinery to work and support a language in CodeCombat, we basically need just one thing: a parser that will turn the source language into a range-annotated Mozilla SpiderMonkey parser AST like Esprima does for JavaScript and CoffeeScript Redux does for CoffeeScript. I have a few more details in a GitHub issue here.

For the js_of_ocaml, it looks like it is an OCaml program itself, not something that can be run to live-transpile JavaScript within the browser? It can produce the JS to handle an OCaml REPL, but we would need something that produced the JS just to handle the parser part of it (code -> abstract syntax tree). We’d also need to convert that AST to the Mozilla format so all the rest of the tools can work on it from there, and do something to figure out basic standard library stuff (since the players need to end up using JavaScript’s standard library stuff for compatibility with the other levels).


Ok, transpiling makes sense, now (though compilation is usually understood in the generic sense of “a semantic-preserving transformation”, e.g. with source-to-source compilation).
Thanks :smiley:

The idea was to compile parts of the OCaml compiler (already known to work) and of js_of_ocaml to JavaScript (using js_of_ocaml itself) in order to get such a pipeline in the browser:

OCaml --ocamlc--> Bytecode --js_of_ocaml--> JavaScript

(js_of_ocaml actually compiles the OCaml bytecode to JS)

So I would need to get such a pipeline to carry also range/location information ?


Yes, so that we can match up the original OCaml statements to the transpiled JS that ends up running for things like flow visualization and error messages. If we were just getting JavaScript out of the js_of_ocaml compiler, without range information, then we can’t just parse that JS again to make the AST that Aether needs. Does the js_of_ocaml compiler support source maps?