[erlang-questions] Reading, Learning, Confused
Edwin Fine
erlang-questions_efine@REDACTED
Mon Jul 21 05:12:24 CEST 2008
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.
In informal syntax notation,
Guard ::= 'when' GuardCondExp
GuardCondExp ::= GuardCond OptTail
OptTail ::= GuardOp GuardCondExp | <empty>
GuardOp ::= ';' | ','
Of course, the semantics, as Richard Carlsson pointed out, in his post are
more complex in terms of which GuardOps can be nested.
Example:
when GuardCond1; GuardCond; GuardCond...; GuardCondN ->
or
when GuardCond1, GuardCond2, GuardCond3, ..., GuardCondN ->
GuardCond1 might be
(X =:=0) or (1/X < 2)
The reference manual is saying that the GuardConds above are
short-circuited, even if the "or"-condition *comprising* GuardCond1 is
*not*short-circuited.
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.
On Sun, Jul 20, 2008 at 3:16 AM, Alpár Jüttner <alpar@REDACTED> wrote:
> What you are writing here is quite irrelevant to the quoted text, as
> Section 6.14 deals with orelse/andelse, it has nothing to do with ,
> and ;.
>
> On the other hand it is not true that the evaluation of guards are
> always short-circuited, in case of 'or' and 'and' both sides are always
> evaluated.
>
> So, I still think that the quoted part of the reference manual is
> erroneous and confusing.
>
> Best regards,
> Alpar
>
> On Sat, 2008-07-19 at 12:11 -0400, Edwin Fine wrote:
> > I interpret those words as follows:
> >
> > As of Erlang 5.5/OTP R11B, short-circuit boolean expressions are
> > allowed in guards. Please note that evaluation is always
> > short-circuited in guards.
> > This is because guard tests are known to be free of side effects. If a
> > guard condition is free of side-effects, that means that in a sequence
> > of guards, it is guaranteed that leaving out the evaluation of one or
> > more guards will not change the state of the program. For example,
> > let's say that user-defined functions were allowed in guards.
> >
> > f(X) -> put(x, X), true.
> > g() -> put(x, true), put(y,"g() was called"), true.
> > h() -> get(x).
> > test(X) when f(X), g(), h() -> ok. % Will not compile - illegal
> > Erlang
> >
> > What will get(x) and get(y) return after test(X) is run? Will it make
> > a difference to the result if guards are not short-circuited?
> >
> > Non-short-circuited guards:
> > test(true): f(true) sets x to true, g() sets x to true, y to the
> > string. End result: x is true, y is "g() was called".
> > test(false): f(false) sets x to false, g() sets x to true. End result:
> > x is true, y is "g() was called".
> >
> > Short-circuited guards with side-effects:
> > test(true): f(true) sets x to true, g() sets x to true, y to the
> > string. End result: x is true, y is "g() was called".
> > test(false): f(false) sets x to false, g() is not evaluated. End
> > result: x is false, y is undefined.
> >
> > So skipping a guard test if it has a side effect can change the state
> > of the whole program, which would make short-circuit evaluation
> > impossible. But because no guard tests can have side-effects, the
> > state of the program cannot be changed if one or more guard tests are
> > not evaluated.
> >
> > Hope this makes sense.
> >
> >
> >
> > On Sat, Jul 19, 2008 at 11:22 AM, Alpár Jüttner <alpar@REDACTED>
> > wrote:
> > > As of Erlang 5.5/OTP R11B, short-circuit boolean
> > expressions are
> > > allowed in guards. In guards, however, evaluation is
> > always
> > > short-circuited since guard tests are known to be
> > free of side
> > > effects.
> > > (Section 6.14, Short-Circuit Boolean Expressions)
> > >
> > > Something is wrong here, isn;t it?
> >
> >
> > I mean
> >
> > * What does the word "however" mean here? Does it mean
> > that if
> > they are not in a guard, orelse/andelse might be non
> > short-circuited?
> > * How does the freedom from side effects are related to
> > the
> > short-circuited evaluation?
> >
> > Regards,
> > Alpar
> >
> >
> > >
> > > Regards,
> > > Alpar
> > >
> > > On Sat, 2008-07-19 at 06:50 -0700, Lev Walkin wrote:
> > > > Sean Allen wrote:
> > > > > by a small bit of example code in Programming Erlang
> > related to guards
> > > > > and short circuit booleans:
> > > > >
> > > > > f(X) when (X == 0) or (1/X > 2) ->
> > > > > ...
> > > > >
> > > > > g(X) when (X == 0) orelse ( 1/X > 2) ->
> > > > > ...
> > > > >
> > > > > The guard in f(X) fails when X is zero but succeeds in
> > g(X)
> > > > >
> > > > > Can someone explain why?
> > > >
> > > >
> > > > Sean,
> > > >
> > > > The thing is, "or" does not short-circuit evaluation when
> > left side
> > > > succeeds, whereas "orelse" does. Same short-circuit logic
> > is
> > > > behind the differences between "and" and "andalso".
> > > >
> > > > Actually, the very book you read explains these
> > differences and warns
> > > > about caveats a couple pages later (or earlier). Don't
> > stop reading.
> > > >
> > >
> > > _______________________________________________
> > > erlang-questions mailing list
> > > erlang-questions@REDACTED
> > > http://www.erlang.org/mailman/listinfo/erlang-questions
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://www.erlang.org/mailman/listinfo/erlang-questions
> >
> >
> >
> > --
> > 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.
> > John F. Kennedy 35th president of US 1961-1963 (1917 - 1963)
>
>
>
--
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.
John F. Kennedy 35th president of US 1961-1963 (1917 - 1963)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080720/9e9ad67f/attachment.htm>
More information about the erlang-questions
mailing list