[erlang-questions] how: Building Core Erlang abstract syntax trees

[Robert Virding]

2008/5/31 Richard Carlsson <richardc@REDACTED>:

> 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
this level:

- I get to generate a simple functional language which has most of what I
need*
- 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
much easier

(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.

Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080601/7719ccc9/attachment.htm>