[eeps] Requests for comment on EEP 26 "Make andalso and orelse tail-recursive"

[Thomas Lindgren]

(Erlang-questions removed from recipients.)

--- On Fri, 1/30/09, Bjorn Gustavsson <bgustavsson@REDACTED> wrote:

> From: Bjorn Gustavsson <bgustavsson@REDACTED>
> Subject: Re: [eeps] Requests for comment on EEP 26 "Make andalso and orelse tail-recursive"
> To: "Robert Virding" <rvirding@REDACTED>
> Cc: eeps@REDACTED, "Erlang Questions" <erlang-questions@REDACTED>
> Date: Friday, January 30, 2009, 12:33 PM
> On Fri, Jan 30, 2009 at 12:09 PM, Robert Virding
> <rvirding@REDACTED> wrote:
> > I support the EEP.
> >
> > What is the reason for not doing the full EEP-17? From
> what I could see the
> > difference was in using andalso and orelse in guards.
> >
> 
> The difference was that EEP-17 suggested that ';'
> and ',' should be allowed to
> be used nested inside parenthesis, and that ';' and
> 'orelse' should be
> equivalent.
> 
> We want ';' to remain syntatic sugar for several
> clauses with the same body,
> that is
> 
> foo(Patterns) when P1; P2 ->
>    Body.
> 
> works the same way as
> 
> foo(Patterns) when P1 ->
>   Body;
> foo(Patterns) when P2 ->
>   Body.
> 
> If P1 causes an exception, but P2 evalutes to true, the
> Body will be executed,
> but in
> 
> foo(Patterns) when P1 orelse P2 ->
>   Body.
> 
> the Body will not be executed if P1 causes an exception.

This distinction seems far too fine to me, not to mention that it adds  complexity. Is it really necessary?

My expectation would indeed be that 'orelse' behaved like ';' in the example above. It is based on the following reasoning:

1. An exception in an atomic guard expression A is considered a guard failure
2. For a guard expression (A orelse B), if A fails, then B will be run.

Point 2 could be expressed more succinctly and declaratively by saying (A orelse B) succeeds if A succeeds or B succeeds, without specifying evaluation order, exception handling versus test failure or whatnot. 

Best,
Thomas