<div dir="ltr">I don't think what I wrote is irrelevant. I think you misunderstood the text in the Reference Manual and what I wrote. So let me try to be more precise.<br><br>In informal syntax notation,<br><br><span style="font-family: courier new,monospace;">Guard ::= 'when' GuardCondExp</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">GuardCondExp ::= GuardCond OptTail</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">OptTail ::= GuardOp GuardCondExp | <empty></span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">GuardOp ::= ';' | ','</span><br><br>Of course, the semantics, as Richard Carlsson pointed out, in his post are more complex in terms of which GuardOps can be nested.<br>
<br>Example:<br><br>when GuardCond1; GuardCond; GuardCond...; GuardCondN -><br><br>or<br><br>when GuardCond1, GuardCond2, GuardCond3, ..., GuardCondN -><br><br>GuardCond1 might be <br><br>(X =:=0) or (1/X < 2)<br>
<br>The reference manual is saying that the GuardConds above are short-circuited, even if the "or"-condition <b>comprising</b> GuardCond1 is <b>not</b> short-circuited.<br><br>FWIW, I agree with ROK when he says don't ever use "and" and "or", and don't use "andalso" and "orelse" in guard conditions - it's error-prone and confusing.<br>
<br><div class="gmail_quote">On Sun, Jul 20, 2008 at 3:16 AM, Alpár Jüttner <<a href="mailto:alpar@cs.elte.hu">alpar@cs.elte.hu</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
What you are writing here is quite irrelevant to the quoted text, as<br>
Section 6.14 deals with orelse/andelse, it has nothing to do with ,<br>
and ;.<br>
<br>
On the other hand it is not true that the evaluation of guards are<br>
always short-circuited, in case of 'or' and 'and' both sides are always<br>
evaluated.<br>
<br>
So, I still think that the quoted part of the reference manual is<br>
erroneous and confusing.<br>
<br>
Best regards,<br>
Alpar<br>
<div><div></div><div class="Wj3C7c"><br>
On Sat, 2008-07-19 at 12:11 -0400, Edwin Fine wrote:<br>
> I interpret those words as follows:<br>
><br>
> As of Erlang 5.5/OTP R11B, short-circuit boolean expressions are<br>
> allowed in guards. Please note that evaluation is always<br>
> short-circuited in guards.<br>
> This is because guard tests are known to be free of side effects. If a<br>
> guard condition is free of side-effects, that means that in a sequence<br>
> of guards, it is guaranteed that leaving out the evaluation of one or<br>
> more guards will not change the state of the program. For example,<br>
> let's say that user-defined functions were allowed in guards.<br>
><br>
> f(X) -> put(x, X), true.<br>
> g() -> put(x, true), put(y,"g() was called"), true.<br>
> h() -> get(x).<br>
> test(X) when f(X), g(), h() ->  ok. % Will not compile - illegal<br>
> Erlang<br>
><br>
> What will get(x) and get(y) return after test(X) is run? Will it make<br>
> a difference to the result if guards are not short-circuited?<br>
><br>
> Non-short-circuited guards:<br>
> test(true): f(true) sets x to true, g() sets x to true, y to the<br>
> string. End result: x is true, y is "g() was called".<br>
> test(false): f(false) sets x to false, g() sets x to true. End result:<br>
> x is true, y is "g() was called".<br>
><br>
> Short-circuited guards with side-effects:<br>
> test(true): f(true) sets x to true, g() sets x to true, y to the<br>
> string. End result: x is true, y is "g() was called".<br>
> test(false): f(false) sets x to false, g() is not evaluated. End<br>
> result: x is false, y is undefined.<br>
><br>
> So skipping a guard test if it has a side effect can change the state<br>
> of the whole program, which would make short-circuit evaluation<br>
> impossible. But because no guard tests can have side-effects, the<br>
> state of the program cannot be changed if one or more guard tests are<br>
> not evaluated.<br>
><br>
> Hope this makes sense.<br>
><br>
><br>
><br>
> On Sat, Jul 19, 2008 at 11:22 AM, Alpár Jüttner <<a href="mailto:alpar@cs.elte.hu">alpar@cs.elte.hu</a>><br>
> wrote:<br>
>         >         As of Erlang 5.5/OTP R11B, short-circuit boolean<br>
>         expressions are<br>
>         >         allowed in guards. In guards, however, evaluation is<br>
>         always<br>
>         >         short-circuited since guard tests are known to be<br>
>         free of side<br>
>         >         effects.<br>
>         >         (Section 6.14, Short-Circuit Boolean Expressions)<br>
>         ><br>
>         > Something is wrong here, isn;t it?<br>
><br>
><br>
>         I mean<br>
><br>
>              * What does the word "however" mean here? Does it mean<br>
>         that if<br>
>                they are not in a guard, orelse/andelse might be non<br>
>                short-circuited?<br>
>              * How does the freedom from side effects are related to<br>
>         the<br>
>                short-circuited evaluation?<br>
><br>
>         Regards,<br>
>         Alpar<br>
><br>
><br>
>         ><br>
>         > Regards,<br>
>         > Alpar<br>
>         ><br>
>         > On Sat, 2008-07-19 at 06:50 -0700, Lev Walkin wrote:<br>
>         > > Sean Allen wrote:<br>
>         > > > by a small bit of example code in Programming Erlang<br>
>         related to guards<br>
>         > > > and short circuit booleans:<br>
>         > > ><br>
>         > > >   f(X) when (X == 0) or (1/X > 2) -><br>
>         > > >      ...<br>
>         > > ><br>
>         > > > g(X) when (X == 0) orelse ( 1/X > 2) -><br>
>         > > >     ...<br>
>         > > ><br>
>         > > > The guard in f(X) fails when X is zero but succeeds in<br>
>         g(X)<br>
>         > > ><br>
>         > > > Can someone explain why?<br>
>         > ><br>
>         > ><br>
>         > > Sean,<br>
>         > ><br>
>         > > The thing is, "or" does not short-circuit evaluation when<br>
>         left side<br>
>         > > succeeds, whereas "orelse" does. Same short-circuit logic<br>
>         is<br>
>         > > behind the differences between "and" and "andalso".<br>
>         > ><br>
>         > > Actually, the very book you read explains these<br>
>         differences and warns<br>
>         > > about caveats a couple pages later (or earlier). Don't<br>
>         stop reading.<br>
>         > ><br>
>         ><br>
>         > _______________________________________________<br>
>         > erlang-questions mailing list<br>
>         > <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
>         > <a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
><br>
>         _______________________________________________<br>
>         erlang-questions mailing list<br>
>         <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
>         <a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
><br>
><br>
><br>
> --<br>
> The great enemy of the truth is very often not the lie -- deliberate,<br>
> contrived and dishonest, but the myth, persistent, persuasive, and<br>
> unrealistic. Belief in myths allows the comfort of opinion without the<br>
> discomfort of thought.<br>
> John F. Kennedy 35th president of US 1961-1963 (1917 - 1963)<br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>The great enemy of the truth is very often not the lie -- deliberate, contrived and dishonest, but the myth, persistent, persuasive, and unrealistic. Belief in myths allows the comfort of opinion without the discomfort of thought.<br>
John F. Kennedy 35th president of US 1961-1963 (1917 - 1963)
</div>