在防护测试中何时更喜欢使用“and”而不是“andalso”

Question

我很好奇为什么在防护测试中逗号 <,> 是 and 的快捷方式，而不是 andalso 。

由于我称自己为“C 本地人”，所以我看不到短路布尔求值的任何缺点。

我使用 to_core 标志编译了一些测试代码，以查看实际生成的代码。使用逗号，我看到左边的值和右边的值都被评估并且都被与了。使用 andalso，您可以在 case 块中包含一个 case 块，并且不会调用 erlang:and/2。

我没有进行基准测试，但我敢说 andalso 变体是更快的。

Answer 1

深入研究过去：

• 最初在守卫中只有，分隔的测试，这些测试从左到右进行评估，直到没有更多的和守卫成功或测试失败并且整个警卫失败。后来添加了 ; 以允许在同一子句中替代守卫。如果警卫在测试之前评估 , 的两侧，那么有人在整个过程中就犯了错误。 @Kay 的示例似乎暗示它们确实按照应有的方式从左到右进行。

• 布尔运算符只在很晚的时候才被允许出现在守卫中。

• and 与 or、xor 和 not 一起是布尔运算符，不适用于控制。它们都是严格并且首先评估它们的参数，例如算术运算符+、-、*和'/ '。 C 中也存在严格的布尔运算符。

• 后来添加了短路控制运算符andalso和orelse来简化一些代码。正如您所说，编译器确实将它们扩展为嵌套的 case 表达式，因此使用它们不会带来性能提升，只是代码的方便性和清晰度。这可以解释您看到的结果代码。

• NB 在守卫中有测试而不是表达式。有一个微妙的区别，这意味着虽然使用 and 和 andalso 等效于 ，但使用 orelse 并不等效到 ;。这留给另一个问题。提示：一切都与失败有关。

所以 and 和 andalso 都有自己的位置。

Answer 2

Adam Lindbergs 链接是正确的。使用逗号确实比使用 andalso 生成更好的光束代码。我使用 +to_asm 标志编译了以下代码：

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.

生成的代码

{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.

我只查看了使用 +to_core 标志生成的内容，但显然 to_core 和 to_asm 之间有一个优化步骤。

Answer 3

布尔运算符“and”和“or”始终评估运算符两边的争论。然而，如果您想要 C 运算符 && 和 || 的功能（其中仅在需要时才评估第二个参数......例如，如果我们想要评估“true” orelse false”，一旦发现第一个参数为 true，则不会评估第二个参数，而使用“or”则不是这种情况） “andalso”和“orelse”。

Answer 4

这是有历史原因的。 and 是在 andalso 之前实现的，后者是在 Erlang 5.1 中引入的（我现在能找到的唯一参考是 EEP-17）。由于向后兼容性，守卫尚未更改。

Answer 5

何时优先使用 andalso 而不是 and：

在某些情况下，我们不希望对第二个表达式求值，例如

L1 = [1, 2, 3].
L2 = [1, 2, 3, 4].
Compare = fun(X, Y) -> X =:= Y end.
Accumulate = fun(X, Acc) -> X and Acc end.
(length(L1) =:= length(L2)) andalso 
  (lists:foldl(Accumulate, true, lists:zipwith(Compare, L1, L2))).

输出：

false

由于 zipwith 期望两个列表的长度相等，如果我们在这里使用 and，第二个表达式（其中包含 zipwith 在两个长度不等的列表上的应用) 也将被评估，导致异常。为了解决这种情况，我们可以使用 andalso 来防止计算第二个表达式。