[erlang-questions] how: Building Core Erlang abstract syntax trees
Sun Jun 1 17:20:53 CEST 2008
2008/5/31 Richard Carlsson <>:
> Christian S wrote:
> > One can use compile:forms/2 to compile core erlang abstract syntax
> > trees directly, but what is the suggested way to construct these
> > trees?
> > There is lib/compile/src/core_parse.* (and especially the records in
> > the hrl file), and there is the 'cerl' module which has good edoc. The
> > module 'cerl' has node-constructors for the core erlang ast.
> > Looking at LFE, it doesnt make use of cerl, it hits the core erlang
> > records directly. Is this an oversight of Robert Virding or the more
> > practical thing to do?
> This is for historical reasons. When we started working on Core Erlang,
> Robert (and others) preferred working directly with records, while I
> preferred using a "proper" abstract datatype (even though it meant
> that I couldn't decompose structures using pattern matching). Also,
> we had some different ideas regarding how some things such as literals
> and variables ought to be represented. So you'll find that the central
> parts of the compiler use the records defined in core_parse.hrl, while
> cerl_inline and everything in lib/hipe/cerl uses the cerl.erl ADT (which
> can be converted to/from the record format).
Also for what I was doing it was just as easy to use records directly. I do
not actually "work" with the Core code, I only build it and pass it directly
into the compiler. Actually this is one Big Win in generating Erlang code at
- I get to generate a simple functional language which has most of what I
- I get to use all the optimisations in the compiler as they work on Core,
and later, code
- the things I lose from the earlier passes I either don't need or can do
(in the next release I have list comprehensions, it's the same algorithm but
in LFE it's a macro and you can actually "see" what it is doing)
So again from my point of view there is no win in using cerl over the
records. At I least I don't know of any.
> Also, Core Erlang allows for annotations, what is the benefits one
> > could have from adding these? Static type analysis or can the compiler
> > make use of them?
One useful feature is tagging clauses as 'compiler_generated' so the
compiler won't complain that they can never be reached.
* What is missing are non-recursive local functions. The reason they are
missing is that they aren't need for compiling Erlang.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions