<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:10pt"><div class="" style=""><span class="" style="">I've heard this explanation before, and it probably explains how it's implemented, but I think it easily leads to confusion. (Much like the rest of Erlang's booleans, unfortunately.) </span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-style: normal; background-color: transparent;" class=""><span class="" style=""><br class="" style=""></span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-style: normal; background-color: transparent;" class="">I'd prefer this, which perhaps should be an EEP: </div><div style="color: rgb(0, 0,
0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-style: normal; background-color: transparent;" class=""><br class="" style=""></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-style: normal; background-color: transparent;" class="">Define guards as (restricted) boolean expressions connected by "," and ";". Disjunctions ";" should furthermore be permitted to be nested with conjunctions ",", which I believe is not the case today. The boolean expressions are known as tests (e.g., "is_integer(X)" or "length(hd(A)) > 0" and are taken from the currently well-known collection of guard tests.</div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-style: normal; background-color:
transparent;" class=""><br class="" style=""></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-style: normal; background-color: transparent;" class="">So, the guard grammar is this:</div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-style: normal; background-color: transparent;" class=""><br class="" style=""></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-style: normal; background-color: transparent;" class="">G ::= G1, G2 | G1 ; G2 | T</div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-style: normal; background-color: transparent;" class=""><br
class="" style=""></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-style: normal; background-color: transparent;" class="">where T is a test. <span style="font-size: 10pt;" class="">Conjunction binds tighter than disjunction and both are associative, so the syntax is nearly the same as what we have today. </span><span style="font-size: 10pt;" class="">As an example, and</span><span class="" style="font-size: 10pt;"> in contrast with today, "G1, (G2 ; G3), G4" is a valid guard if G1 to G4 are valid guards (which may themselves contain "," and ";" if so desired).</span></div><div style="color: rgb(0, 0, 0); font-size: 10pt; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-style: normal; background-color: transparent;" class=""><span style="background-color: transparent;" class=""><br class=""
style=""></span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-style: normal; background-color: transparent;" class=""><span style="background-color: transparent;" class="">Conjunction "," means logical AND, while disjunction ";" means logical OR. AND/OR are lazily evaluated left to right. Thus, in the grammar above, G1 is evaluated before G2, and G2 is not evaluated unless required. </span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-style: normal; background-color: transparent;" class=""><span style="background-color: transparent;" class=""><br class="" style=""></span></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-style: normal;
background-color: transparent;" class="">Tests T that fail/crash or do not return a boolean are treated as if they evaluate to false. (Subexpressions can of course evaluate to non-booleans. If a subexpression crashes during evaluation, the whole test fails.) <br class="" style=""></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-style: normal; background-color: transparent;" class=""><br class="" style=""></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-style: normal; background-color: transparent;" class="">Finally, if the guard of a clause evaluates to false, the clause head fails and evaluation moves on to try to match the next clause.</div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue',
Helvetica, Arial, 'Lucida Grande', sans-serif; font-style: normal; background-color: transparent;" class=""><br class="" style=""></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-style: normal; background-color: transparent;" class="">In this approach, andalso/orelse/and/or can possibly be permitted as tests (or subexpressions of tests), but I'd suggest to not allow them in guard contexts since they lead to the (needless) ambiguities discussed above.</div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-style: normal; background-color: transparent;" class=""><br class="" style=""></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-style: normal;
background-color: transparent;" class="">(Other connectives like negation and implication could also be allowed, as well as more powerful tests, but I'll leave that for future work.)</div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-style: normal; background-color: transparent;" class=""><br class="" style=""></div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-style: normal; background-color: transparent;" class="">Best,</div><div style="color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-style: normal; background-color: transparent;" class="">Thomas</div><div class="yahoo_quoted" style="display: block;"> <div style="font-family: HelveticaNeue, Helvetica Neue,
Helvetica, Arial, Lucida Grande, sans-serif; font-size: 10pt;" class=""> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 12pt;" class=""> <div dir="ltr" class="" style=""> <font size="2" face="Arial" class="" style=""> On Monday, May 19, 2014 10:33 AM, Håkan Huss <huss01@gmail.com> wrote:<br class="" style=""> </font> </div> <blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; margin-top: 5px; padding-left: 5px;" class=""> <br class="" style=""><br class="" style=""> <div class="" style=""><div id="yiv1785441146" class="" style=""><div class="" style=""><div dir="ltr" class="" style=""><div class="" style="">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 clear="none" class="" style="">
<br clear="none" class="" style=""></div>/Håkan<br clear="none" class="" style=""></div><div class="" style=""><br clear="none" class="" style=""><br clear="none" class="" style=""><div class="" style="">2014-05-19 2:59 GMT+02:00 Fred Hebert <span dir="ltr" class="" style=""><<a rel="nofollow" shape="rect" ymailto="mailto:mononcqc@ferd.ca" target="_blank" href="mailto:mononcqc@ferd.ca" class="" style="">mononcqc@ferd.ca</a>></span>:<br clear="none" class="" style="">
<div class="" id="yiv1785441146yqt59934" style=""><blockquote class="" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="" style="">On 05/19, Richard A. O'Keefe wrote:<br clear="none" class="" style="">
><br clear="none" class="" style="">
><br clear="none" class="" style="">
> This is seriously misleading.<br clear="none" class="" style="">
><br clear="none" class="" style="">
> The difference between X > Y , X < Z<br clear="none" class="" style="">
> and X > Y andalso X < Z<br clear="none" class="" style="">
> with respect to exceptions has NOTHING TO DO with whether<br clear="none" class="" style="">
> it's comma or andalso. The right semantic model is that<br clear="none" class="" style="">
> it is the tests X > Y and X < Z themselves which change.<br clear="none" class="" style="">
> If a guard test would have raised an exception, that<br clear="none" class="" style="">
> turns into a simple failure of the guard test.<br clear="none" class="" style="">
><br clear="none" class="" style="">
> Example:<br clear="none" class="" style="">
><br clear="none" class="" style="">
> 1> F1 = fun (X) when X+1 > 2 -> ok ; (_) -> oops end.<br clear="none" class="" style="">
> 2> F2 = fun (X) -> B = (X + 1 > 2), if B -> ok ; true -> oops end end.<br clear="none" class="" style="">
> 3> F1(snark).<br clear="none" class="" style="">
> oops<br clear="none" class="" style="">
> 4> F2(snark).<br clear="none" class="" style="">
> ** exited: {badarith,...} **<br clear="none" class="" style="">
><br clear="none" class="" style="">
> This being so, "," never gets to *see* an exception,<br clear="none" class="" style="">
> so how could it catch one?<br clear="none" class="" style="">
><br clear="none" class="" style="">
> You can't verify Fred's statement, because it isn't true.<br clear="none" class="" style="">
> "," and ";" no more catch exceptions than "->" does.<br clear="none" class="" style="">
><br clear="none" class="" style="">
<br clear="none" class="" style="">
</div>There is no practical difference between ',' and 'andalso' in any way,<br clear="none" class="" style="">
because as you mentioned, an exception would turn into a failure of the<br clear="none" class="" style="">
guard test no matter which one is used. This would be the same no matter<br clear="none" class="" style="">
what the implementation as far as I can tell.<br clear="none" class="" style="">
<br clear="none" class="" style="">
For ';' and 'orelse', there is a practical difference. They don't<br clear="none" class="" style="">
properly 'catch' exceptions, but when learning Erlang I've found the<br clear="none" class="" style="">
explanation I used in LYSE useful and practically applicable (which is<br clear="none" class="" style="">
why I put it in the book).<br clear="none" class="" style="">
<br clear="none" class="" style="">
Of course you can look at the assembler or even at the result of fun2ms<br clear="none" class="" style="">
to see an example of the practical difference:<br clear="none" class="" style="">
<br clear="none" class="" style="">
1> ets:fun2ms(fun(X) when hd(X) > 0 orelse true -> ok end).<br clear="none" class="" style="">
[{'$1',[{'orelse',{'>',{hd,'$1'},0},true}],[ok]}]<br clear="none" class="" style="">
2> ets:fun2ms(fun(X) when hd(X) > 0; true -> ok end).<br clear="none" class="" style="">
[{'$1',[{'>',{hd,'$1'},0}],[ok]},<br clear="none" class="" style="">
{'$1',[true],[ok]}]<br clear="none" class="" style="">
<br clear="none" class="" style="">
Showing an example interpretation where the clauses are entirely<br clear="none" class="" style="">
disjoint and more equivalent to two different function clauses than a<br clear="none" class="" style="">
logical operator when observed that way. The same way calling the<br clear="none" class="" style="">
function:<br clear="none" class="" style="">
<br clear="none" class="" style="">
f([]) -> a;<br clear="none" class="" style="">
f(_) -> b.<br clear="none" class="" style="">
<br clear="none" class="" style="">
as f([]) doesn't result in the first clause 'catching' a badmatch<br clear="none" class="" style="">
exception, the ';' doesn't end up catching exceptions either. It's just<br clear="none" class="" style="">
that I personally found the simple rule I put in LYSE to be good enough<br clear="none" class="" style="">
and understandable.<br clear="none" class="" style="">
<br clear="none" class="" style="">
The other comparison point I used in the text was 'nesting' with<br clear="none" class="" style="">
parentheses:<br clear="none" class="" style="">
<br clear="none" class="" style="">
> However (there is always a 'however'), only andalso and orelse can be<br clear="none" class="" style="">
> nested inside guards. This means (A orelse B) andalso C is a valid<br clear="none" class="" style="">
> guard, while (A; B), C is not. Given their different use, the best<br clear="none" class="" style="">
> strategy is often to mix them as necessary.<br clear="none" class="" style="">
<br clear="none" class="" style="">
I believe I ended up grouping ',' and ';', 'andalso' and 'orelse', and<br clear="none" class="" style="">
'and' and 'or' (that's a confusing sentence) in the explanations of this<br clear="none" class="" style="">
chapter because they just fit well together in pairs. That did end up<br clear="none" class="" style="">
suggesting ',' catches exceptions, while it clearly shouldn't.<br clear="none" class="" style="">
<br clear="none" class="" style="">
People are of course free to question the method I used there and to<br clear="none" class="" style="">
disagree with it. I won't be debating it in much detail because, as I<br clear="none" class="" style="">
said, I felt entirely satisfied with the method I used to explain it,<br clear="none" class="" style="">
and felt it is more easily understandable than going into the details of<br clear="none" class="" style="">
how everything gets compiled lower down.<br clear="none" class="" style="">
<br clear="none" class="" style="">
LYSE probably papers over a lot of issues in that manner, especially in<br clear="none" class="" style="">
the earlier chapters. That's both a result of me writing the book as the<br clear="none" class="" style="">
entire learning experience was still fresh in my mind (and I reported<br clear="none" class="" style="">
things as they made sense to me back then), and not wanting to get into<br clear="none" class="" style="">
details before people are even able to compile code.<br clear="none" class="" style="">
<br clear="none" class="" style="">
I'm hoping, for the benefit of their own learning experience, that<br clear="none" class="" style="">
readers who feel like getting a more formal approach to learning Erlang<br clear="none" class="" style="">
likely wouldn't pick the book with the weird squid and badly written<br clear="none" class="" style="">
title over the other alternatives. Hopefully I can't be accused of false<br clear="none" class="" style="">
representation on the book's cover and tone.<br clear="none" class="" style="">
<br clear="none" class="" style="">
I'm also hoping people are generally satisfied with LYSE, but of course,<br clear="none" class="" style="">
there's no guarantee, and the errata of the book[1] only proves I am able<br clear="none" class="" style="">
to make a ton of mistakes.<br clear="none" class="" style="">
<br clear="none" class="" style="">
Regards,<br clear="none" class="" style="">
Fred.<br clear="none" class="" style="">
<br clear="none" class="" style="">
[1] <a rel="nofollow" shape="rect" target="_blank" href="http://www.nostarch.com/erlang#updates" class="" style="">http://www.nostarch.com/erlang#updates</a> (click on 'show updates')<br clear="none" class="" style="">
<div class="" style=""><div class="" style="">_______________________________________________<br clear="none" class="" style="">
erlang-questions mailing list<br clear="none" class="" style="">
<a rel="nofollow" shape="rect" ymailto="mailto:erlang-questions@erlang.org" target="_blank" href="mailto:erlang-questions@erlang.org" class="" style="">erlang-questions@erlang.org</a><br clear="none" class="" style="">
<a rel="nofollow" shape="rect" target="_blank" href="http://erlang.org/mailman/listinfo/erlang-questions" class="" style="">http://erlang.org/mailman/listinfo/erlang-questions</a><br clear="none" class="" style="">
</div></div></blockquote></div></div><br clear="none" class="" style=""></div></div></div><br class="" style=""><div class="" id="yqt21089" style="">_______________________________________________<br clear="none" class="" style="">erlang-questions mailing list<br clear="none" class="" style=""><a shape="rect" ymailto="mailto:erlang-questions@erlang.org" href="mailto:erlang-questions@erlang.org" class="" style="">erlang-questions@erlang.org</a><br clear="none" class="" style=""><a shape="rect" href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank" class="" style="">http://erlang.org/mailman/listinfo/erlang-questions</a><br clear="none" class="" style=""></div><br class="" style=""><br class="" style=""></div> </blockquote> </div> </div> </div> </div></body></html>