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

[Stavros Aronis]

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

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!
* 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.

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.

Regards,

Stavros