Quantcast

Core erlang definition

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Core erlang definition

Robert Virding
Does there exist a current definition ofCore Erlang? I know you can look in cerl.erl to see which constructions exist but there is a lot which is unclear on how they are to be used. For example one problem I had was HOW to represent literals. They can either be done by having them literally (haha) inside a #c_lit{} record or as a whole nested tree of Core records. I noticed that even if these are in principle equivalent sometimes later passes of the compile required one or the other to work.

I got it working in the LFE compiler but it feels a bit risky not to be certain why it works, and what might happen if I change things.

Robert


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Core erlang definition

Richard Carlsson-3
The Core Erlang home page is still up: https://www.it.uu.se/research/group/hipe/cerl/

Caveat: the spec has not been updated with the changes for bitstrings and maps. Would be nice to do that some day...

The optimal way to represent literals tends to vary between passes, so there's never a clear-cut choice. If you use the cerl.erl module, you'll find some utility functions like fold_literal/1 and unfold_literal/1, is_literal_term/1, etc., that can take care of the details. For example, cons_hd/1 and cons_tl/1 will give you the head subtree even if the argument is a literal list.


        /Richard

2017-03-16 17:32 GMT+01:00 Robert Virding <[hidden email]>:
Does there exist a current definition ofCore Erlang? I know you can look in cerl.erl to see which constructions exist but there is a lot which is unclear on how they are to be used. For example one problem I had was HOW to represent literals. They can either be done by having them literally (haha) inside a #c_lit{} record or as a whole nested tree of Core records. I noticed that even if these are in principle equivalent sometimes later passes of the compile required one or the other to work.

I got it working in the LFE compiler but it feels a bit risky not to be certain why it works, and what might happen if I change things.

Robert


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Core erlang definition

Björn Gustavsson-4
On Thu, Mar 16, 2017 at 10:59 PM, Richard Carlsson
<[hidden email]> wrote:

> The optimal way to represent literals tends to vary between passes, so
> there's never a clear-cut choice. If you use the cerl.erl module, you'll
> find some utility functions like fold_literal/1 and unfold_literal/1,
> is_literal_term/1, etc., that can take care of the details. For example,
> cons_hd/1 and cons_tl/1 will give you the head subtree even if the argument
> is a literal list.

It is true that literals may be differently represented
within different passes, but some passes (sys_core_fold,
v3_kernel) make implicit assumptions that a literal
is represented as #c_literal{}. Breaking those assumptions
can lead to sub-optimal code or possibly even compiler
crashes.

/Bjorn

--
Björn Gustavsson, Erlang/OTP, Ericsson AB
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Core erlang definition

Robert Virding
So this means that when you are representing data structures/patterns they should be "as literal as possible"? And only use explicit structures, for example #c_cons{}/#c_tuple{}, when they have elements which aren't literal values?

Robert


On 17 March 2017 at 15:52, Björn Gustavsson <[hidden email]> wrote:
On Thu, Mar 16, 2017 at 10:59 PM, Richard Carlsson
<[hidden email]> wrote:

> The optimal way to represent literals tends to vary between passes, so
> there's never a clear-cut choice. If you use the cerl.erl module, you'll
> find some utility functions like fold_literal/1 and unfold_literal/1,
> is_literal_term/1, etc., that can take care of the details. For example,
> cons_hd/1 and cons_tl/1 will give you the head subtree even if the argument
> is a literal list.

It is true that literals may be differently represented
within different passes, but some passes (sys_core_fold,
v3_kernel) make implicit assumptions that a literal
is represented as #c_literal{}. Breaking those assumptions
can lead to sub-optimal code or possibly even compiler
crashes.

/Bjorn

--
Björn Gustavsson, Erlang/OTP, Ericsson AB


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Core erlang definition

Björn Gustavsson-4
On Fri, Mar 17, 2017 at 8:31 PM, Robert Virding <[hidden email]> wrote:
> So this means that when you are representing data structures/patterns they
> should be "as literal as possible"? And only use explicit structures, for
> example #c_cons{}/#c_tuple{}, when they have elements which aren't literal
> values?

Yes, that's how v3_core represents literals when translating to Core Erlang.

That said, I just come to think about some changes we have made in
sys_core_fold in the master branch (to be OTP 20). Starting from
OTP 20, sys_core_fold will do a fix point iteration on each function,
that is, perform all transformations again and again until there is
no further change (or until the limit for the max number of iterations
is reached).

That probably means that it does not matter as much how literals
are represented. If the literals are not "as literal as possible", the
first round through sys_core_fold will make them "as literal as
possible". Subsequent rounds can then do the appropriate
optimizations.

/Björn

--
Björn Gustavsson, Erlang/OTP, Ericsson AB
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Loading...