This is a bit off topic, but I wish there was some sort of tutorial or book on HOW to make a new language for the BEAM.
It seems like a lot of fun but I have no idea where to start lol. O
Implementing languages on the BEAM by Robert Virding & Mariano Guerra
9 Likes
Not a tutorial as such, but in Erlang/OTP 29 there will be some recommendations for developers of new languages running on the BEAM:
11 Likes
Interestingā¦. If compiling to .BEAM is so highly discouraged, why do Gleam and Cure do it?
Also, is there a reference/specification on how the Erlang ast works?
1 Like
Canāt say anything about Gleam, but Cure is literally forced to do it to preserve correctness proof.
3 Likes
AFAIK the Gleam compiler produces .erl files, and I may be wrong, but it looks like Cure compiles to AST, not .beam
See
Edit: A brief scan through the Cure repo leads me to believe itās producing Erlang .ast from the .cure files, then compiling to .beam using compile:forms
4 Likes
Correct. Cure compiles to erlang forms, and then to .beam.
4 Likes
Yay!
I think I was just trying to clarify that Cure is not producing itās own BEAM code independently of the Erlang compiler, which is what I believe @bjorng was actually referring to in his documentation PR Update compiler and erlc documentation
5 Likes
There are many reasons it does not, and the main is I am not a moron to try to outperform F1 car on my VW Beetle.
5 Likes
Maybe take a look at all the existing attempts and learn and get inspiration from them!
3 Likes
There are quite a few books on complier design, https://craftinginterpreters.com has been mentioned a few times on EF by @linusdm. Was also mentioned by @LincolnBryant here:
Itās also #1 in Amazonās Best Sellers in Compiler Design list:
3 Likes
There are probably limitations on what kind of languages you can make on the BEAM though right? Like, Lox from crafting interpreters requires mutation Iām pretty sure, and idk how youād represent something like C with pointers and manual memory management.
Though I know there was a project that tries to compile Rust to C#/.NET Bytecode so itās obviously not impossible
2 Likes
Iām not sure what those limitations might be tbhā¦ you could ask our resident expert, @rvirding, who, if I am not mistaken, has created more BEAM languages than anyone else - including Erlang itself 
2 Likes
Yeah I guess the main thing Iām thinking about is that Iām pretty sure all values in the BEAM are boxed, and thereās no such thing as a struct. Meanwhile .NET has both struct and classes, and the JVM with project Valhalla is getting āvalue classesā
1 Like
Itās Turing Complete so you can do anything. 
ā¦ however just because you can do something doesnāt mean you should. Building a C compiler to target the BEAM wouldnāt result in anything truly useful.
4 Likes
Yes, and no. Technically you can do whatever you want. Realistically the BEAM runtime is Erlang semantics. So you are limited by what Erlang is good at.
3 Likes
In runtime you are limited, thatās correct. In compile time you are absolutely free to do any weird stuff, as I (hopefully) successfully demonstrated with Cure.
3 Likes
Rustās borrow checker would have been implemented with (backed up by) a process, which might be crucial, to begin with.
I have an experience trying to compile Ruby to BEAM and trust me mutable object <> process interop is not anything one wants to deal with.
2 Likes
This all can be solved during the compilation stage, so that particular issue is a piece of cake. Unless one needs reflection and/or aspect-oriented programming.
2 Likes
Yes, there is link to it from the pull request, although that link is a little bit cryptic in the Markdown format. Here is a direct link:
Yes, that was what I meant.
I am not sure whether any language developer has ever tried to produce BEAM files directly.
I can recommend another book, which includes a section describing how to implement a simple interpreted language (hoc) using yacc. Thatās how I got started implementing (simple) compilers and interpreters.
7 Likes