I’d like a lisp that would compile into Elixir modules. It’s not very hard to do, only a little boring because of little details such as designing a sensible standard library, tooling, sourcemaps, etc. You would know, of course xD
Why Elixir and not Erlang?
First, being able to interoperate with Elixir macros is huge, and Elixir’s AST oddities (like do blocks and the internal __block__ node) map relatively well to lisp’s progn or the scheme equivalents. With one or two helper macros, one could use Phoenix as is. This interoperability alone makes ir worth it to compile to Elixir instead of Erlang. Phoenix’s “guts” very well designed (PubSub, Channels, Presence), although one might dislike some surface characteristics. And Phoenix is so easy to customize that it doesn’t matter anyway.
Phoenix was basically the only reason I went for Elixir instead of LFE. One can debate the timeless beauty of lisp until the cows come home, but Elixir has Phoenix and Phoenix has channels, and channels are shiny and modern and won me over xD
Second, compiling to Elixir means we can use elixir’s tooling: Mix as a build tool (with a custom compiler), ExDoc for documentation and the new BEAM chunks for documentation and better error reporting in pattern matches.
I’m not familiar with the Erlang equivalents (rebar and erldoc), but again, Mix makes it easy to integrate with Elixir libraries.
@OvermindDL1 has been working on a toy implementation, which nonetheless has read macro support.
This project on Github also implements a lisp interpreter on Elixir with static types and HM type inference: GitHub - smpoulsen/terp: A functional programming language with lisp syntax and ML semantics that runs on the BEAM · GitHub
