[erlang-questions] Order of evaluation of guards

[Robert Virding]

That the ',' is not short circuit is an implementation detail, and the
wrong choice at that. Originally guards were evaluated from left-to-right
and as soon as a test failed the guard failed, the ',' was short
circuiting. This was also consistent with ';' alternate guards which was
also left-to-right and short-circuiting, as soon as one of the guard
sequences succeeded the whole guard succeeded.

I don't know when ',' became strict but it was never intended to be that.
It should behave the same as 'andalso' and not as 'and'.

Note that there is one very significant difference between ';' and
or/orelse and that is how they behave with errors. ';' will just fail that
one guard sequence and attempt the next one while or/orelse will fail the
guard sequence they are in. So if they are used as an alternative to ';'
you will get different behaviour.

That errors in guards cause the guard to fail and not generate an exception
was an intentional design decision, it saved a lot of explicit type tests
and they were implicit in the operations. For example you could do
tuple_size(T) without first having to check if T is a tuple.

Robert


On 5 January 2015 at 12:36, Jesper Louis Andersen <
jesper.louis.andersen@REDACTED> wrote:

> Hi,
>
> Guard order don't matter! You are limited to a small set of expressions
> and BIFs in guards. All of these are guaranteed to be total in the sense
> that either producing a result or terminating. By not defining a rule for
> guard order, the compiler is free to reorder guard expressions as it sees
> fit. It can also cache results of guard expressions, since they won't
> change during the pattern match evaluation.
>
>
> On Mon Jan 05 2015 at 10:18:37 AM Ivan Uemlianin <ivan@REDACTED> wrote:
>
>> The main thing is ; is applied first, so your guard was like:
>>
>> (( N > 0, M > 0, N < 100) ; (M < 100))
>>
>> Then the whole single expression is evaluated.
>>
>> Ivan
>>
>> --
>> festina lente
>>
>>
>> > On 5 Jan 2015, at 09:04, Martin Koroudjiev <mrtndimitrov@REDACTED>
>> wrote:
>> >
>> > Hi, thanks. So the "and" (,) is evaluated first and since (,) is not
>> > short circuit  all will be replaced with true/false. And then the "or"
>> > will be evaluated.
>> >
>> >
>> >> On 1/5/2015 10:57 AM, Ivan Uemlianin wrote:
>> >> The last is correct according to your guards: M < 100. Perhaps you
>> could try:
>> >>
>> >>  ... when N > 0, M > 0, N < 100;
>> >>          N > 0, M > 0, M < 100 -> ...
>> >>
>> >> Happy New Year!
>> >>
>> >> Ivan
>> >>
>> >> --
>> >> festina lente
>> >>
>> >>
>> >>> On 5 Jan 2015, at 08:51, Martin Koroudjiev <mrtndimitrov@REDACTED>
>> wrote:
>> >>>
>> >>> Hello,
>> >>>
>> >>> First of all - Happy New Year!
>> >>>
>> >>> Suppose we have a function that accepts 2 integers and we want to
>> react
>> >>> only when both integers are greater than 0 and one of them is less
>> than 100:
>> >>>
>> >>> I tried:
>> >>> (dilbert@REDACTED)1> F = fun(N, M) when N > 0, M > 0, N < 100; M <
>> 100
>> >>> -> cool; (_, _) -> not_cool end.
>> >>> #Fun<erl_eval.12.106461118>
>> >>> (dilbert@REDACTED)2> F(1,2).
>> >>> cool
>> >>> (dilbert@REDACTED)3> F(1,200).
>> >>> cool
>> >>> (dilbert@REDACTED)4> F(0,200).
>> >>> not_cool
>> >>> (dilbert@REDACTED)5> F(0,50).
>> >>> cool
>> >>>
>> >>> The last is not correct.
>> >>> What is the order of evaluation of the guards? Sadly parentheses are
>> not
>> >>> allowed in guards.
>> >>>
>> >>> Best regards,
>> >>> Martin
>> >>>
>> >>> _______________________________________________
>> >>> erlang-questions mailing list
>> >>> erlang-questions@REDACTED
>> >>> http://erlang.org/mailman/listinfo/erlang-questions
>> >
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150105/aca6029c/attachment.htm>