[erlang-questions] concurrency developments

[Richard Carlsson]

Robert Virding wrote:
> If you are going to compile to Core then you need the following files as 
> help:
>     core_parse.hrl
>     core_lint.erl
>     core_pp.erl

There are some additional files in lib/hipe/cerl, which may be of
interest, in particular cerl_prettypr.erl, which is an alternative
prettyprinter based on the prettypr library (part of syntax_tools).
It does a better job of formatting than the naive core_pp version.

> Then it's just core_lint it to be sure and run it in to the back-end of 
> the compiler to generate module. Works really well.

The core_lint pass can simply be enabled by passing the option 'clint'
to the compiler, as in c(foo, [from_core,clint]).

> The best way to truly understand how it all fits together is to generate 
> core code "c(foo,[report,to_core])" and stare at it a bit. Most becomes 
> clear then.

Amen. The specification document tries to be precise, but gives you few
hints on how it all fits together with the Beam compiler. Looking at
some concrete code is the way to go.

> One major benefit of compiling to core, apart from it being a nice 
> little language, is that you get some significant optimisations done for 
> you in the back-end. A major one is the pattern-matching compiler which 
> works on core code.

Yes. Note that when you compile with the to_core flag, you get the
unoptimized translation from plain Erlang, and when you compile with
the from_core flag, the compiler will run all the Core level
optimizations before moving on down to lower level code.

It is also possible to specify -compile({core_transform, Module})
in a module, similar to parse_transforms. (Or just pass {core_transform, 
Module} as an option.) These transforms are run after the Core level
optimizations, so you can rely on being given better code. Pattern
matching compilation is done after these transforms however, so the
user does not have to worry about doing that himself (and will not
be bothered by horrible deeply nested case switches).

While I'm at it: primops are only used for quite special stuff on this
level (operations that don't officially exist as Erlang functions, but
which need to be represented somehow), and you won't see a lot of that.
Operators such as '+' are simply represented as calls using their full
names: erlang:'+'(A,B). (These are optimized to primitives much later.)
So don't be worried  about where all the built-in operations are.

     /Richard