[erlang-questions] difference between ", " and "andalso" in guards

[Fred Hebert]

On 05/19, Richard A. O'Keefe wrote:
> 
> 
> This is seriously misleading.
> 
> The difference between  X > Y , X < Z
> and X > Y andalso X < Z
> with respect to exceptions has NOTHING TO DO with whether
> it's comma or andalso.  The right semantic model is that
> it is the tests X > Y and X < Z themselves which change.
> If a guard test would have raised an exception, that
> turns into a simple failure of the guard test.
> 
> Example:
> 
> 1> F1 = fun (X) when X+1 > 2 -> ok ; (_) -> oops end.
> 2> F2 = fun (X) -> B = (X + 1 > 2), if B -> ok ; true -> oops end end.
> 3> F1(snark).
> oops
> 4> F2(snark).
> ** exited: {badarith,...} **
> 
> This being so, "," never gets to *see* an exception,
> so how could it catch one?
> 
> You can't verify Fred's statement, because it isn't true.
> "," and ";" no more catch exceptions than "->" does.
> 

There is no practical difference between ',' and 'andalso' in any way,
because as you mentioned, an exception would turn into a failure of the
guard test no matter which one is used. This would be the same no matter
what the implementation as far as I can tell.

For ';' and 'orelse', there is a practical difference. They don't
properly 'catch' exceptions, but when learning Erlang I've found the
explanation I used in LYSE useful and practically applicable (which is
why I put it in the book).

Of course you can look at the assembler or even at the result of fun2ms
to see an example of the practical difference:

1> ets:fun2ms(fun(X) when hd(X) > 0 orelse true -> ok end).
[{'$1',[{'orelse',{'>',{hd,'$1'},0},true}],[ok]}]
2> ets:fun2ms(fun(X) when hd(X) > 0; true -> ok end).
[{'$1',[{'>',{hd,'$1'},0}],[ok]},
 {'$1',[true],[ok]}]

Showing an example interpretation where the clauses are entirely
disjoint and more equivalent to two different function clauses than a
logical operator when observed that way. The same way calling the
function:

f([]) -> a;
f(_) -> b.

as f([]) doesn't result in the first clause 'catching' a badmatch
exception, the ';' doesn't end up catching exceptions either. It's just
that I personally found the simple rule I put in LYSE to be good enough
and understandable.

The other comparison point I used in the text was 'nesting' with
parentheses:

> However (there is always a 'however'), only andalso and orelse can be
> nested inside guards. This means (A orelse B) andalso C is a valid
> guard, while (A; B), C is not. Given their different use, the best
> strategy is often to mix them as necessary.

I believe I ended up grouping ',' and ';', 'andalso' and 'orelse', and
'and' and 'or' (that's a confusing sentence) in the explanations of this
chapter because they just fit well together in pairs. That did end up
suggesting ',' catches exceptions, while it clearly shouldn't.

People are of course free to question the method I used there and to
disagree with it. I won't be debating it in much detail because, as I
said, I felt entirely satisfied with the method I used to explain it,
and felt it is more easily understandable than going into the details of
how everything gets compiled lower down.

LYSE probably papers over a lot of issues in that manner, especially in
the earlier chapters. That's both a result of me writing the book as the
entire learning experience was still fresh in my mind (and I reported
things as they made sense to me back then), and not wanting to get into
details before people are even able to compile code.

I'm hoping, for the benefit of their own learning experience, that
readers who feel like getting a more formal approach to learning Erlang
likely wouldn't pick the book with the weird squid and badly written
title over the other alternatives. Hopefully I can't be accused of false
representation on the book's cover and tone.

I'm also hoping people are generally satisfied with LYSE, but of course,
there's no guarantee, and the errata of the book[1] only proves I am able
to make a ton of mistakes.

Regards,
Fred.

[1] http://www.nostarch.com/erlang#updates (click on 'show updates')