When to prefer `and` over `andalso` in guard tests

Question

I am curious why the comma ‹,› is a shortcut for and and not andalso in guard tests.

Since I'd call myself a “C native” I fail to see any shortcomings of short-circuit boolean evaluation.

I compiled some test code using the to_core flag to see what code is actually generated. Using the comma, I see the left hand value and right and value get evaluated and both and'ed. With andalso you have a case block within the case block and no call to erlang:and/2.

I did no benchmark tests but I daresay the andalso variant is the faster one.

Answer 1

To delve into the past:

• Originally in guards there were only , separated tests which were evaluated from left-to-right until either there were no more and the guard succeeded or a test failed and the guard as a whole failed. Later ; was added to allow alternate guards in the same clause. If guards evaluate both sides of a , before testing then someone has gotten it wrong along the way. @Kay's example seems to imply that they do go from left-to-right as they should.

• Boolean operators were only allowed much later in guards.

• and, together with or, xor and not, is a boolean operator and was not intended for control. They are all strict and evaluate their arguments first, like the arithmetic operators +, -, * and '/'. There exist strict boolean operators in C as well.

• The short-circuiting control operators andalso and orelse were added later to simplify some code. As you have said the compiler does expand them to nested case expressions so there is no performance gain in using them, just convenience and clarity of code. This would explain the resultant code you saw.

• N.B. in guards there are tests and not expressions. There is a subtle difference which means that while using and and andalso is equivalent to , using orelse is not equivalent to ;. This is left to another question. Hint: it's all about failure.

So both and and andalso have their place.

Answer 2

Adam Lindbergs link is right. Using the comma does generate better beam code than using andalso. I compiled the following code using the +to_asm flag:

a(A,B) ->     case ok of         _ when A, B -> true;         _ -> false     end. aa(A,B) ->     case ok of         _ when A andalso B -> true;         _ -> false     end. 

which generates

{function, a, 2, 2}.   {label,1}.     {func_info,{atom,andAndAndalso},{atom,a},2}.   {label,2}.     {test,is_eq_exact,{f,3},[{x,0},{atom,true}]}.     {test,is_eq_exact,{f,3},[{x,1},{atom,true}]}.     {move,{atom,true},{x,0}}.     return.   {label,3}.     {move,{atom,false},{x,0}}.     return.  {function, aa, 2, 5}.   {label,4}.     {func_info,{atom,andAndAndalso},{atom,aa},2}.   {label,5}.     {test,is_atom,{f,7},[{x,0}]}.     {select_val,{x,0},{f,7},{list,[{atom,true},{f,6},{atom,false},{f,9}]}}.   {label,6}.     {move,{x,1},{x,2}}.     {jump,{f,8}}.   {label,7}.     {move,{x,0},{x,2}}.   {label,8}.     {test,is_eq_exact,{f,9},[{x,2},{atom,true}]}.     {move,{atom,true},{x,0}}.     return.   {label,9}.     {move,{atom,false},{x,0}}.     return. 

I only looked into what is generated with the +to_core flag, but obviously there is a optimization step between to_core and to_asm.