在 Haskell 中，对于递归函数使用守卫比模式更好吗？

Question

我只是想知道我在 Haskell 中布置的递归函数。对于递归函数来说，使用防护通常比使用模式更好吗？

我只是不确定最好的布局是什么，但我确实知道在定义这样的函数时模式更好：

units :: Int -> String

units 0 = "zero"
units 1 = "one"

比

units n
    | n == 0 = "zero"
    | n == 1 = "one"

我只是不确定在递归时这是否相同或不同。

只是不太确定术语：我正在使用这样的东西：

f y [] = [] 
f y (x:xs) 
    | y == 0 = ...... 
    | otherwise = ...... 

或者这会更好吗？

f y [] = [] 
f 0 (x:xs) = 
f y (x:xs) =

Answer 1

到目前为止的答案没有提到模式匹配的优点，这对我来说最重要：安全实现全部功能的能力。

在进行模式匹配时，您可以安全地访问对象的内部结构，而不必担心该对象是其他对象。如果您忘记了某些模式，编译器会向您发出警告（不幸的是，该警告在 GHC 中默认关闭）。

例如，在编写以下内容时：

map f xs | null xs   = []
         | otherwise = f (head xs) : map f (tail xs)

您被迫使用非总函数 head 和 tail，从而冒着程序生命周期的风险。如果您在保护条件中犯了错误，编译器将无法帮助您。

另一方面，如果您在模式匹配方面出错，编译器可以根据错误的严重程度给出错误或警告。

一些例子：

-- compiles, crashes in runtime
map f xs | not (null xs)   = []
         | otherwise = f (head xs) : map f (tail xs)

-- does not have any way to compile
map f (h:t) = []
map f [] = f h : map f t


-- does not give any warnings
map f xs = f (head xs) : map f (tail xs)

-- can give a warning of non-exhaustive pattern match
map f (h:t) = f h : map f t

Answer 2

我的一般经验法则是：

• 当防护是一个简单的 == 检查时，使用模式匹配。

通过递归，您通常会检查基本情况。因此，如果您的基本情况是简单的 == 检查，则使用模式匹配。

所以我通常会这样做：

map f [] = []
map f (x:xs) = f x : map f xs

而不是这样（null 只是检查列表是否为空。它基本上是 == []）：

map f xs | null xs   = []
         | otherwise = f (head xs) : map f (tail xs)

模式匹配旨在使您的生活更轻松，恕我直言，所以最终你应该做对你有意义的事情。如果你与一个团队一起工作，那么就做对团队有意义的事情。

[更新]

对于您的特定情况，我会做这样的事情：

f _ []      = []
f 0 _       = ...
f y (x:xs)  = ...

模式匹配，如守卫，从上到下下降，停止在与输入匹配的第一个定义处。我使用下划线符号来指示对于第一个模式匹配，我不关心 y 参数是什么，对于第二个模式匹配，我不关心列表参数是什么（不过，如果您在该计算中使用列表，则不应使用下划线）。由于它仍然是相当简单的类似 == 的检查，因此我个人坚持使用模式匹配。

但我认为这是个人喜好的问题；您的代码完全可读且正确。如果我没记错的话，当编译代码时，守卫和模式匹配最终都会变成 case 语句。

Answer 3

一个简单的规则

• 如果您在数据结构上递归，请使用模式匹配。
• 如果您的递归条件更复杂，请使用防护。

讨论

从根本上来说，这取决于您希望执行的测试来保护递归。如果是对数据类型结构的测试，请使用模式匹配，因为它比冗余的相等测试更有效。

对于您的示例，整数上的模式匹配显然更干净、更高效：

units 0 = "zero"
units 1 = "one"

对任何数据类型的递归调用也是如此，您可以通过数据的形状来区分情况。

现在，如果你有更复杂的逻辑条件，那么守卫就有意义了。

Answer 4

这方面并没有真正硬性规定，这就是为什么你得到的答案有点模糊。有些决定很简单，例如在 [] 上进行模式匹配，而不是使用 f xs | 进行保护。 null xs = ... 或者，天堂不允许，f xs | length xs == 0 = ... 这在很多方面都很糟糕。但是，当没有令人信服的实际问题时，只需使用使代码更清晰的那个即可。

例如，考虑以下函数（它们实际上并没有做任何有用的事情，只是用作说明）：

f1 _ [] = [] 
f1 0 (x:xs) = [[x], xs]
f1 y (x:xs) = [x] : f1 (y - 1) xs

f2 _ [] = []
f2 y (x:xs) | y == 0    = calc 1 : f2 (- x) xs
            | otherwise = calc (1 / y) : f2 (y * x) xs
  where calc z = x * ...

在 f1 中，单独的模式强调递归有两个基本情况。在f2中，守卫强调0只是某些计算的特例（其中大部分是由calc完成的，在where中定义）子句由守卫的两个分支共享）并且不会改变计算的结构。

Answer 5

@Dan 是正确的：这基本上是个人喜好的问题，不会影响生成的代码。该模块：

module Test where

units :: Int -> String
units 0 = "zero"
units 1 = "one"

unitGuarded :: Int -> String
unitGuarded n
  | n == 0 = "zero"
  | n == 1 = "one"

产生了以下核心：

Test.units =
  \ (ds_dkU :: GHC.Types.Int) ->
    case ds_dkU of _ { GHC.Types.I# ds1_dkV ->
    case ds1_dkV of _ {
      __DEFAULT -> Test.units3;
      0 -> Test.unitGuarded2;
      1 -> Test.unitGuarded1
    }
    }

Test.unitGuarded =
  \ (n_abw :: GHC.Types.Int) ->
    case n_abw of _ { GHC.Types.I# x_ald ->
    case x_ald of _ {
      __DEFAULT -> Test.unitGuarded3;
      0 -> Test.unitGuarded2;
      1 -> Test.unitGuarded1
    }
    }

完全相同，除了不同的默认情况，这在两种情况下都是模式匹配错误。 GHC 甚至将匹配案例的字符串共用起来。