2008/5/31 Richard Carlsson <<a href="mailto:richardc@it.uu.se">richardc@it.uu.se</a>>:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Christian S wrote:<br>
> One can use compile:forms/2 to compile core erlang abstract syntax<br>
> trees directly, but what is the suggested way to construct these<br>
> trees?<br>
><br>
> There is lib/compile/src/core_parse.* (and especially the records in<br>
> the hrl file), and there is the 'cerl' module which has good edoc. The<br>
> module 'cerl' has node-constructors for the core erlang ast.<br>
><br>
 > Looking at LFE, it doesnt make use of cerl, it hits the core erlang<br>
 > records directly. Is this an oversight of Robert Virding or the more<br>
 > practical thing to do?<br>
<br>
</div>This is for historical reasons. When we started working on Core Erlang,<br>
Robert (and others) preferred working directly with records, while I<br>
preferred using a "proper" abstract datatype (even though it meant<br>
that I couldn't decompose structures using pattern matching). Also,<br>
we had some different ideas regarding how some things such as literals<br>
and variables ought to be represented. So you'll find that the central<br>
parts of the compiler use the records defined in core_parse.hrl, while<br>
cerl_inline and everything in lib/hipe/cerl uses the cerl.erl ADT (which<br>
can be converted to/from the record format).<br>
</blockquote><div><br>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:<br>
<br>- I get to generate a simple functional language which has most of what I need*<br>- I get to use all the optimisations in the compiler as they work on Core, and later, code<br>- the things I lose from the earlier passes I either don't need or can do much easier<br>
<br>(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)<br><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">> Also, Core Erlang allows for annotations, what is the benefits one<br>

> could have from adding these? Static type analysis or can the compiler<br>
> make use of them?</div></blockquote><div><br>One useful feature is tagging clauses as 'compiler_generated' so the compiler won't complain that they can never be reached.<br><br>
* What is missing are non-recursive local functions. The reason they are missing is that they aren't need for compiling Erlang.<br>
<br>
Robert</div></div><br>