[erlang-questions] Reading, Learning, Confused

Edwin Fine erlang-questions_efine@REDACTED
Sat Jul 19 18:11:26 CEST 2008


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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080719/3ebafbd9/attachment.htm>


More information about the erlang-questions mailing list