On the use of Core Erlang vs Abstract Syntax by tools after 23.0

[Björn Gustavsson]

On Mon, Jun 8, 2020 at 1:59 PM Stavros Aronis <aronisstav@REDACTED> wrote:
>
> Hi,
>
> As a maintainer of Concuerror I was a little surprised to see that
> Core Erlang generated by the 23.0 compiler no longer has any 'receive'
> constructs. Such constructs have now been replaced by a number of
> other primitive operations. I discussed this a little bit with Kostis
> yesterday and I just noticed that he has opened a bug report here:
> https://bugs.erlang.org/browse/ERL-1277

The reason for the change is EEP 52 which allows map keys and sizes of
segments in binary pattern matching to be expressions.

> While I can see a path forward for Concuerror
> (https://github.com/parapluu/Concuerror/issues/312#issuecomment-640272985
> , tl;dr: we can probably do the instrumentation at abstract syntax
> level), other tools may not be so fortunate. My take from the
> discussion yesterday is that now one has to pick a poison:
>
> * if one wants receive statements to have a concise form, with e.g.
> their patterns easily accessible, then they should stay in abstract
> syntax and not use Core Erlang, as in Core Erlang receive is now
> replaced by primitive operations and the patterns can end up being
> nested in arbitrary ways. As an aside, it would be great if the
> semantics of the new primops is given "somewhere", as receive is kind
> of... central in Erlang!

Yes, we should probably write some internal documentation that
documents the primops and how we use Core Erlang.

Also note that an ordinary case can be rewritten into nested cases if
one of the patterns in the case has map key or binary size which is an
expression (that is, when the new features introduced in EEP 52 are
used) and also for patterns such as:

<<Size:16,Tail:Size>> = Bin

> * if one wants other nice language characteristics, such as e.g. a
> well defined scope for variables, then one cannot use abstract syntax
> and has to go to Core Erlang.

For binary matching, the scope of the variable is now far easier to
understand. The special rule for binary patterns in the last paragraph
of section 6.5 of the Core Erlang is no longer implemented or used.
("Note that within a binary pattern #{b1, . . ., bn}#, a variable
bound by one bit string pattern bi can be used in the arguments of
another bj, i < j ≤ n, shadowing any previous bindings of that
variable in the current environment.") Correctly implementing that
rule in all Core Erlang passes has been a constant headache.

> If that is indeed the case, it looks like a pain that should probably
> be more visible. It is unfortunate that Core Erlang's specification is
> not maintained, and it is unfortunate that yet another rift is now
> there.

I do think that this way to implement EEP 52 is the least invasive
change to how we use Core Erlang in the compiler. Allowing and
supporting expressions in map keys and segment sizes would be a real
change to the Core Erlang specification and would complicate all
passes that do something with Core Erlang.

/Bjorn

-- 
Björn Gustavsson, Erlang/OTP, Ericsson AB