[erlang-questions] concurrency developments

[Bob Calco]

Oz also has this concept of a "core" syntax that is a strict subset of the
"syntactic sugar" version developers work in, with similar correctness and
ease-of-reasoning goals.

In any case, this is GREAT stuff... I'm not even more jazzed than I was
before about my little pet project. I'm very glad to see so much support for
what I'm trying to do already there and ready to be used.

It's going to be hard for me to stay focused on the day job now ...

:)

- Bob

> -----Original Message-----
> From: Richard Carlsson [mailto:richardc@REDACTED]
> Sent: Thursday, January 17, 2008 5:21 PM
> To: Robert Virding
> Cc: bobcalco@REDACTED; erlang-questions@REDACTED;
> dmercer@REDACTED
> Subject: Re: [erlang-questions] concurrency developments
> 
> 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