Other languages generating code like Elixir does

[mguimas]

@OvermindDL1

The prime example is missed though, Lisp, it’s macro’s are both fast and all encompassing, able to generate anything as they are very normal code.

An actual or future form of Lisp will win at the end

[hauleth]

@OvermindDL1

I’m not sure if Rusts even are

AFAIK there is no proof yet and I think they tried very hard to not be, however I do not know how it is with specialisation.

@OvermindDL1

The lifeblood that makes templates so much nicer to use!

I think it is the place where we highly disagree.

@OvermindDL1

The prime example is missed though, Lisp, it’s macro’s are both fast and all encompassing, able to generate anything as they are very normal code.

Which should also be the case for Elixir, as Lisps’ macros works similarly to Elixir ones AFAIK.

[mguimas]

I disagree with you with respect to this

… as Lisps’ macros works similarly to Elixir ones AFAIK.

For the following case they are not similar in practice. One difficulty I have with Elixir macros is that it is not always straightforward to see where to put my unquotes so that they generate a correct AST. This is because the concrete and abstract syntax are different, and there is no solution to make the process easier, except practicing, practicing …

A real Lisp, one in which there is no concrete and abstract distinction, there is no such problem.

Despite this, I like Elixir macros, and think they are the biggest selling point of Elixir with respect to other BEAM languages, the other selling points being Phoenix and Ecto.

The other alternative to Elixir could be LFE, but this seems death with no visible activity, not even a single reference in the Erlang Solutions page (unfortunately).

[OvermindDL1]

@mguimas

The other alternative to Elixir could be LFE, but this seems death with no visible activity, not even a single reference in the Erlang Solutions page (unfortunately).

I keep poking @rvirding to add read-macro’s.

It wouldn’t be too hard to have lfe work well with Elixir with a good hoisting library either.

[hauleth]

You mean like @wojtekmach hello_beam project? Only thing that I currently dislike in Elixir vs BEAM is tooling separation. Almost everything (except Elixir) uses Rebar3 (with some exceptions that use erlang.mk), and Elixir uses it’s own tooling that is completely separate. I do not even know if there are Mix compilers for LFE, Joxa, or others.

[OvermindDL1]

@hauleth I’ve use lfe as a dependency before from hex.pm.

But don’t forget that mix can use rebar deps and rebar can call things from hex.pm.

[Qqwy]

One important language still missing here is Forth, whose ‘code generation’ methodology is again very different from the other languages here (although in some ways it can be considered a ‘postfix lisp’, in that the language and its AST are one and the same thing), in that read code is immediately transformed into ‘bytecode’ (all Forth functions (which in Forth parlance are called ‘words’) have both a compile-time implementation (which usually is just ‘add a reference to the run-time implementation to the current function body being compiled’) and a run-time implementation).

Basically, Forth currently might be the (or at least one of the) languages that is easiest to implement on top of a new stack, because there is only a very small amount of bootstrapping necessary before the rest of the system can be written in Forth. As an example, you might want to look at 64th which is a full ANSI-Forth-compatible implementation for 64-bit Intel assembly. There is also a great talk about how this was built, if you want to know more.

[OvermindDL1]

I love forth, it is such a fun language, both to implement and use, I highly recommend learning it just for the fun of it. ^.^

[rvirding]

The major difficulty I think with using LFE together with elixir is that many elixir packages use macros in their interface. This means that equivalent LFE macros would need to be written to comfortably use these packages as the “raw” function interface is probably not well defined. While this would probably not be difficult it would take some effort. This problem also exists if you want to use these packages from Erlang.

Think of being able to use phoenix and ecto from LFE and erlang.

@OvermindDL1 unfortunately character read macros wouldn’t help you here.

[OvermindDL1]

@rvirding

The major difficulty I think with using LFE together with elixir is that many elixir packages use macros in their interface. This means that equivalent LFE macros would need to be written to comfortably use these packages as the “raw” function interface is probably not well defined. While this would probably not be difficult it would take some effort. This problem also exists if you want to use these packages from Erlang.

Precisely. That is what such an ‘elixir library for lfe’ would do, it would be a set of lisp macro’s that replace elixir macro’s (maybe even going far enough to converter between an elixir ast and some DSL ast in lfe for ease of ‘binding’).

@rvirding

@OvermindDL1 unfortunately character read macros wouldn’t help you here.

Nope, but I like read-macro’s for making very nice DSEL’s. Plus you could always do something like write inline elixir and feed it through the elixir compiler to get an output and then convert that erlang ast (or a subset there-of) to lfe’s ast.