<div dir="ltr">The compiler doesn't really "reorder" the clauses. It builds a match tree depending on types, values and variables. In the current implementation it does so by inspecting all clauses left to right.<div><br></div><div>You can inspect the matching tree by compiling to kernel, i.e. erlc +to_kernel t.erl</div><div><br></div><div>// Björn-Egil</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-04-01 20:57 GMT+02:00 Fred Hebert <span dir="ltr"><<a href="mailto:mononcqc@ferd.ca" target="_blank">mononcqc@ferd.ca</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 04/01, Pierre Fenoll wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ferd on IRC mentioned that the compiler might feel free to reorder clauses.<br>
</blockquote>
<br></span>
The compiler would only reorder clauses that are free to do so.<br>
<br>
For example:<br>
<br>
   f(a) -> 1;<br>
   f(b) -> 2;<br>
   f(X) when is_atom(X) -> 3;<br>
   f([_|_]) -> 4;<br>
   f({_}) -> 5.<br>
<br>
Would let the compiler possibly reorder 1 & 2, and maybe 4 & 5. But the presence of a guard clause or ambiguous matches would prevent it from doing more than that, if my understanding is accurate.<br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
</blockquote></div><br></div>