Erlex is a (WIP!) project to create a tool that can translate Erlang
into correct, idiomatic Elixir.
In principle, it could be used on any existing code
(e.g., examples, libraries, frameworks, applications).
Erlex is intended to be both modular and extensible.
For example, it should be easy to add handling
for additional idioms, test frameworks, etc.
In the general case, programming language translation is a difficult problem,
requiring compiler-compilers, deep semantic analysis, etc.
However, doing a rough translation (i.e., a transliteration)
of Erlang to Elixir should be comparatively easy:
Erlang is a syntactically simple language.
Elixir is a semantic superset of Erlang.
Erlex can lean on Erlang and Elixir tools.
Starting with this rough translation, we can look for ways to polish it
(e.g., use Elixir's convenience macros and idioms).
Although some polishing tasks may be AI-complete,
I suspect that many cases will be reasonably straightforward.
Erlang's abstract format (i.e., AST) is available in two forms.
The raw form is a direct encoding of the language syntax.
Core Erlang, in contrast, uses a simplified subset of language features,
resolves some scoping issues, etc.
Although Core Erlang is easier to analyze, it is linguistically "further" from Elixir.
Given that Elixir provides a superset of Erlang's features,
it should be possible to do direct mappings of language constructs,
with no need for deeper structural analysis.
So, I expect to concentrate on the raw Erlang AST,
reserving Core Erlang (and direct code parsing) for emergencies.
Here is a plausible, albeit high-level, data flow diagram for Erlex:
The outer two (solid) arrows, conveniently, are no problem.
Using Erlang's :epp.parse_file/2 function, we can generate
the code's abstract format (i.e., AST).
And, using Elixir's Macro.to_string/1 function,
we can turn an Elixir AST into nicely-formatted Elixir code.
The inner two (dashed) arrows, however, indicate major challenges.
First, we must extract critical information from the Raw Erlang AST
and translate it into a Raw Elixir AST.
Then, we must polish the AST,
replacing awkward language usage patterns with idiomatic Elixir.
Elixir's Enum.reduce/3 macro and pattern matching capabilities
seem well suited for these tasks, but the details are still somewhat fuzzy.
For example, we may need to use multiple levels of pattern matching,
in order to handle complex situations.
Note: Thanks to Arthur Colle, James Fish, Richard Jones, Noah Kantrowitz, Martin Karlsson,
Alexander Songe, and Robert Virding for valuable hints, pointers, etc.
This wiki page is maintained by Rich Morin,
an independent consultant specializing in software design, development, and documentation.
Please feel free to email
comments, inquiries, suggestions, etc!