<div dir="ltr"><div>Isn't the easiest way to explain the difference between E1; E2 and E1 orelse E2 is that the former is two guards combined with ; while the latter is one guard containing an orelse operator. If E1 would give an exception, E1 fails in the first case, and the next guard is evaluated. In the second case, if E1 would give an exception the (only) guard fails.<br>
<br></div>/Håkan<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-05-19 2:59 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"><div class="">On 05/19, Richard A. O'Keefe wrote:<br>
><br>
><br>
> This is seriously misleading.<br>
><br>
> The difference between  X > Y , X < Z<br>
> and X > Y andalso X < Z<br>
> with respect to exceptions has NOTHING TO DO with whether<br>
> it's comma or andalso.  The right semantic model is that<br>
> it is the tests X > Y and X < Z themselves which change.<br>
> If a guard test would have raised an exception, that<br>
> turns into a simple failure of the guard test.<br>
><br>
> Example:<br>
><br>
> 1> F1 = fun (X) when X+1 > 2 -> ok ; (_) -> oops end.<br>
> 2> F2 = fun (X) -> B = (X + 1 > 2), if B -> ok ; true -> oops end end.<br>
> 3> F1(snark).<br>
> oops<br>
> 4> F2(snark).<br>
> ** exited: {badarith,...} **<br>
><br>
> This being so, "," never gets to *see* an exception,<br>
> so how could it catch one?<br>
><br>
> You can't verify Fred's statement, because it isn't true.<br>
> "," and ";" no more catch exceptions than "->" does.<br>
><br>
<br>
</div>There is no practical difference between ',' and 'andalso' in any way,<br>
because as you mentioned, an exception would turn into a failure of the<br>
guard test no matter which one is used. This would be the same no matter<br>
what the implementation as far as I can tell.<br>
<br>
For ';' and 'orelse', there is a practical difference. They don't<br>
properly 'catch' exceptions, but when learning Erlang I've found the<br>
explanation I used in LYSE useful and practically applicable (which is<br>
why I put it in the book).<br>
<br>
Of course you can look at the assembler or even at the result of fun2ms<br>
to see an example of the practical difference:<br>
<br>
1> ets:fun2ms(fun(X) when hd(X) > 0 orelse true -> ok end).<br>
[{'$1',[{'orelse',{'>',{hd,'$1'},0},true}],[ok]}]<br>
2> ets:fun2ms(fun(X) when hd(X) > 0; true -> ok end).<br>
[{'$1',[{'>',{hd,'$1'},0}],[ok]},<br>
 {'$1',[true],[ok]}]<br>
<br>
Showing an example interpretation where the clauses are entirely<br>
disjoint and more equivalent to two different function clauses than a<br>
logical operator when observed that way. The same way calling the<br>
function:<br>
<br>
f([]) -> a;<br>
f(_) -> b.<br>
<br>
as f([]) doesn't result in the first clause 'catching' a badmatch<br>
exception, the ';' doesn't end up catching exceptions either. It's just<br>
that I personally found the simple rule I put in LYSE to be good enough<br>
and understandable.<br>
<br>
The other comparison point I used in the text was 'nesting' with<br>
parentheses:<br>
<br>
> However (there is always a 'however'), only andalso and orelse can be<br>
> nested inside guards. This means (A orelse B) andalso C is a valid<br>
> guard, while (A; B), C is not. Given their different use, the best<br>
> strategy is often to mix them as necessary.<br>
<br>
I believe I ended up grouping ',' and ';', 'andalso' and 'orelse', and<br>
'and' and 'or' (that's a confusing sentence) in the explanations of this<br>
chapter because they just fit well together in pairs. That did end up<br>
suggesting ',' catches exceptions, while it clearly shouldn't.<br>
<br>
People are of course free to question the method I used there and to<br>
disagree with it. I won't be debating it in much detail because, as I<br>
said, I felt entirely satisfied with the method I used to explain it,<br>
and felt it is more easily understandable than going into the details of<br>
how everything gets compiled lower down.<br>
<br>
LYSE probably papers over a lot of issues in that manner, especially in<br>
the earlier chapters. That's both a result of me writing the book as the<br>
entire learning experience was still fresh in my mind (and I reported<br>
things as they made sense to me back then), and not wanting to get into<br>
details before people are even able to compile code.<br>
<br>
I'm hoping, for the benefit of their own learning experience, that<br>
readers who feel like getting a more formal approach to learning Erlang<br>
likely wouldn't pick the book with the weird squid and badly written<br>
title over the other alternatives. Hopefully I can't be accused of false<br>
representation on the book's cover and tone.<br>
<br>
I'm also hoping people are generally satisfied with LYSE, but of course,<br>
there's no guarantee, and the errata of the book[1] only proves I am able<br>
to make a ton of mistakes.<br>
<br>
Regards,<br>
Fred.<br>
<br>
[1] <a href="http://www.nostarch.com/erlang#updates" target="_blank">http://www.nostarch.com/erlang#updates</a> (click on 'show updates')<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>