Comment by nwalkr

> all the Erlang formats can be decompiled into Erlang source code

Nope, I'm not buying. This is roughly "any executable binary can be decompiled to C" which is kinda true, but we both know it's not how the real world works. Compilation is lossy, parsing to AST is almost lossless.

> the cost of compiling to source

But now you paid this cost a second time. To build textual Erlang source programmatically, you need some kind of AST anyway, as I highly doubt you were using direct text templating. So you had an incomplete copy of Erlang Abstract Format, which is THE Erlang AST, but had to write your own pretty-printing.

If I were to implement code generation targeting BEAM in language X I would start with making some tool(in Erlang) to fetch abstract format definition from erl_parse typespecs and make code generator to X emitting matching definitions and ETF serialization code. It is relatively simple, it is unavoidable anyway, and it lets me avoid bothering with textual Erlang puctuation.

I just don't get it. It's not even fun!

Also I'm currently playing with idea of compiling Core Erlang via OCaml backend, there is a mirror problem - parsing of Core into OCaml terms. And no way I'm implementing proper lexing/parsing of Core, I'm going with ETF right from start.