为什么应该在函数式编程中使用应用函子？

Question

我是 Haskell 的新手，我正在阅读有关函子和应用函子的内容。好的，我了解函子以及如何使用它们，但我不明白为什么 applicative 函子有用以及如何在 Haskell 中使用它们。你能用一个简单的例子向我解释为什么我需要应用函子吗？

Answer 1

应用函子是一种提供函子和monad，因此比 monad 更广泛，而比函子更有用。通常，您可以将函数映射到函子上。应用函子允许您采用“普通”函数（采用非函子参数），使用它来对函子上下文中的多个值进行操作。作为推论，这可以让您在没有 monad 的情况下进行有效的编程。

可以在此处找到充满示例的精彩、独立的解释。您还可以阅读 由 Bryan O'Sullivan 开发的实用解析示例，不需要任何先验知识。

Answer 2

当您需要对操作进行排序但不需要命名任何中间结果时，应用函子非常有用。因此，它们比 monad 弱，但比函子强（它们没有显式绑定运算符，但它们确实允许在函子内运行任意函数）。

它们什么时候有用？一个常见的示例是解析，您需要运行多个操作来按顺序读取数据结构的各个部分，然后将所有结果粘合在一起。这就像函数组合的一般形式：

f a b c d

您可以将 a、b 等视为要运行的任意操作，而 f > 作为应用于结果的函子。

f <
gt; a <*> b <*> c <*> d

我喜欢将它们视为超载的“空白”。或者，常规 Haskell 函数位于恒等应用函子中。

请参阅“带效果的应用程序编程”

Answer 3

Conor McBride 和 Ross Paterson 关于这种风格的功能性珍珠有几个很好的例子。它还首先负责推广这种风格。他们使用术语“习语”来表示“应用函子”，但除此之外，它是很容易理解的。

Answer 4

很难举出需要应用函子的例子。我可以理解为什么中级 Haskell 程序员会问自己这个问题，因为大多数介绍性文本都提供从 Monad 派生的实例，仅使用 Applicative Functors 作为方便的接口。

正如这里和该主题的大多数介绍中所提到的，关键的见解是应用函子位于函子和 Monad 之间（甚至位于函子和箭头之间）。所有 Monad 都是 Applicative Functor，但并非所有 Functor 都是 Applicative。

因此，有时我们可以使用应用组合器来做一些我们不能使用单子组合器的事情。其中之一是 ZipList （另请参阅这个SO问题详细信息），它只是列表的包装，以便拥有一个与列表的 Monad 实例派生的不同的 Applicative 实例。应用文档使用以下行给出了 ZipList 用途的直观概念：

f <
gt; ZipList xs1 <*> ... <*> ZipList xsn = ZipList (zipWithn f xs1 ... xsn)

正如所指出的

Cafe/2009-April/059088.html" rel="nofollow noreferrer">这里 是其他不是 Monad 的应用函子（请参阅 这个 SO问题）而且它们很容易想出来。拥有 Monad 的替代接口固然很好，但有时制作 Monad 效率低下、复杂，甚至不可能，而这就是您需要应用函子的时候。

---

免责声明：制作应用函子也可能效率低下、复杂且不可能，如有疑问，请咨询您当地的范畴理论家以正确使用应用函子。

Answer 5

根据我的经验，应用函子非常有用，原因如下：

某些类型的数据结构允许强大的组合类型，但不能真正成为单子。事实上，函数式反应式编程中的大多数抽象都属于这一类。虽然我们在技术上可能能够将例如Behavior（又名Signal）作为一个monad，但通常无法有效地完成。应用函子让我们在不牺牲效率的情况下仍然拥有强大的组合（诚然，有时使用应用函子比使用单子更棘手，只是因为你没有那么多的结构可以使用）。

应用函子中缺乏数据依赖性，允许您在没有可用数据的情况下遍历一个动作，寻找它可能产生的所有效果。因此，您可以想象一个“网络表单”应用程序，如下所示：

userData = User <
gt; field "Name" <*> field "Address"

您可以编写一个引擎，该引擎将遍历以查找使用的所有字段并将它们显示在表单中，然后当您获取数据时再次运行它以获取构造了用户。这不能用普通函子（因为它将两种形式组合为一种）来完成，也不能用 monad 来完成，因为用 monad 你可以表达：

userData = do
    name <- field "Name"
    address <- field $ name ++ "'s address"
    return (User name address)

无法渲染，因为在没有响应的情况下无法知道第二个字段的名称从一开始。我很确定有一个库可以实现这个表单的想法——我已经为这个和那个项目推出了几次自己的库。

应用函子的另一个好处是它们可以组合。 组合函子：

newtype Compose f g x = Compose (f (g x))

更准确地说，只要 f 和 g 存在， 就适用。对于 monad 来说则不然，它创造了整个 monad 转换器的故事，在一些令人不快的方面变得复杂。这样，应用程序就非常干净，这意味着您可以通过专注于小型可组合组件来构建所需类型的结构。

最近 GHC 中出现了 ApplicativeDo 扩展，它允许您在应用程序中使用 do 表示法，只要您不执行任何 monady 操作，就可以减轻一些表示法的复杂性事物。

Answer 6

一个很好的例子：应用解析。

请参阅 [真实世界 haskell] 第 16 章 http://book.realworldhaskell.org/read/ using-parsec.html#id652517

这是带有 do-notation 的解析器代码：

-- file: ch16/FormApp.hs
p_hex :: CharParser () Char
p_hex = do
  char '%'
  a <- hexDigit
  b <- hexDigit
  let ((d, _):_) = readHex [a,b]
  return . toEnum $ d

使用函子使其更短：

-- file: ch16/FormApp.hs
a_hex = hexify <
gt; (char '%' *> hexDigit) <*> hexDigit
    where hexify a b = toEnum . fst . head . readHex $ [a,b]

“提升”可以隐藏某些重复代码的底层细节。那么你可以用更少的单词来告诉准确的&精确的故事。

Answer 7

我还建议看看这个

文章中有一个示例

import Control.Applicative
hasCommentA blogComments =
BlogComment <
gt; lookup "title" blogComments
            <*> lookup "user" blogComments
            <*> lookup "comment" blogComments

，它说明了应用程序编程风格的几个特征。