[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.
/Richard
More information about the erlang-questions
mailing list