[erlang-questions] Core Erlang questions

Richard Carlsson richardc@REDACTED
Thu Oct 16 14:21:58 CEST 2008

Lars-Åke Fredlund wrote:
> Thank you for the explanation, which made the definition much 
> clearer.
> Anyway I  wasn't worrying, I was rather hoping :-) that it was 
> impossible to have very "complicated" expressions. In a sense having 
> a very simple input format where "computation" (calling functions, 
> receive, case, etc) of expressions only takes place in let arguments,
>  and the let body only composes basic values and variables using 
> simple data constructors. The Core Erlang output from compile:file 
> (with option 'to_core') seems (in my limited testing experience) to 
> respect this.

That was another design decision: whether or not to enforce A-normal
form. In the end we decided that it was more flexible to allow free
form code, and let anyone who wanted a restricted form do their own
transformation prepass. The compiler generated code does not so much
"respect" a normal form as it "happens to end up something like that".

If you add 'inline' to the options, you will see more compact Core code.

> Essentially I want to implement a transformation lifting a 
> subexpression with a receive out from its expression context, and if 
> that receive expression can occur at an arbitrary depth the task will
>  be a bit harder (not much, but a bit). Anyway, the separation
> between returning a value and variable binding enforced in Core
> Erlang (through the requirement to a sequence of one element) will
> help.

Perhaps surprisingly, I've never had to implement such a normal-form
prepass, even though I though I'd need to sooner or later. Maybe I
just never attacked a kind of transformation problem where it would
have been useful.


More information about the erlang-questions mailing list