问题标签 [alternative-functor]

_{这很可能是一个寻求问题的解决方案......如果是这样，我请求你的宽容！}

可能的实现：

解释是：给定一个成功的计算，让它失败；给定一个失败的计算，让它成功。我不确定，但这似乎与 MonadPlus 正好相反……如果你眯着眼睛真的很用力的话。？？？

这个概念是否有标准类型类或其他实现？如果有的话，底层数学会是什么样子（即这是一个半群、一个循环等）？

从类的名称和解析器中的用法来看，Maybe我认为它的行为是从a <|> b <|> c. 所以我希望输入

它将返回第一个非空列表，即：

但它实际上只是连接了整个事情，产生：

所以我想知道这种实现背后的原因是什么？它真的正确吗？

http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Applicative.html#t:Alternative

PS是否有任何标准功能可以满足我的期望Alternative？

我发现很多我自己拼凑起来的东西似乎很有用，实际上有一个我不知道的标准实现，所以很好奇是否有人可以说他们以前见过这种类型的东西：

它接受一个单子函数并将其折叠，直到一个谓词被替代选择，然后它返回谓词的结果：

我意识到这个名字是一个前奏冲突，我可能会用别的名字来命名它，但我想我会先看看在我不知道的标准库中是否已经有类似的功能......

此外，我想我很好奇我写的组合替代方案是否在其他地方定义，或者这些功能中的任何一个似乎一开始就被误导了。但我的问题的症结是，这是在其他地方实现的，还是在其他地方实现的非常相似的东西

UsingControl.Applicative对 Parsec 非常有用，但是您需要始终隐藏<|>和类似的对象，因为它们与 Parsec 自己的冲突：

或者，正如 Antal SZ 指出的那样，您可以隐藏 Parsec 版本。然而，据我所知，这似乎是一个不必要的限制。

为什么 parsec 不简单地从 Applicative 实现这些运算符？

假设我有这种解析器类型：

这个原子解析器单元：

解析器实现了这三个接口：

satisfy现在据我了解，我现在可以通过使用应用程序接口进行链接来弹出更高级别的抽象并构建更复杂的解析器。例如：

太好了，现在如果我想构造一个计算，以便解析器解析流中的所有大写字母，直到遇到小写字母，该怎么办？用例：

我如何表达这种不确定长度的概念？

Alternative, 的扩展Applicative, 声明empty,<|>和这两个函数：

一个或多个：

零个或多个：

如果定义，some并且many应该是方程的最小解：

我找不到定义some和的实例many。它们的意义和实际用途是什么？它们完全被使用了吗？仅仅从这个定义我就无法理解他们的目的。

更新：我不是在问什么是Alternative，只是什么是some和many

ZipList comes with a Functor and an Applicative instance (Control.Applicative) but why not Alternative?

• Is there no good instance?
• What about the one proposed below?
  • Is it flawed?
  • is it useless?
  • Are there other reasonable possibilities (like Bool can be a monoid in two ways) and therefore neither should be the instance?

I searched for "instance Alternative ZipList" (with the quotes to find code first) and only found the library, some tutorials, lecture notes yet no actual instance.

Matt Fenwick said ZipList A will only be a monoid if A is (see here). Lists are monoids though, regardless of the element type.

This other answer by AndrewC to the same question discusses how an Alternative instance might look like. He says

There are two sensible choices for Zip [1,3,4] <|> Zip [10,20,30,40]:

1. Zip [1,3,4] because it's first - consistent with Maybe
2. Zip [10,20,30,40] because it's longest - consistent with Zip [] being discarded

where Zip is basically ZipList.

I think the answer should be Zip [1,3,4,40]. Let's see the instance:

The only Zip a we can produce without knowing the type argument a is Zip [] :: Zip a, so there is little choice for empty. If the empty list is the neutral element of the monoid, we might be tempted to use list concatenation. However, go is not (++) because of the drop 1. Every time we use one entry of the first argument list, we drop one off the second as well. Thus we have a kind of overlay: The left argument list hides the beginning of the right one (or all of it).

One intuition behind ziplists is processes: A finite or infinite stream of results. When zipping, we combine streams, which is reflected by the Applicative instance. When the end of the list is reached, the stream doesn't produce further elements. This is where the Alternative instance comes in handy: we can name a concurrent replacement (alternative, really), taking over as soon as the default process terminates.

For example we could write fmap Just foo <|> pure Nothing to wrap every element of the ziplist foo into a Just and continue with Nothing afterwards. The resulting ziplist is infinite, reverting to a default value after all (real) values have been used up. This could of course be done by hand, by appending an infinite list inside the Zip constructor. Yet the above is more elegant and does not assume knowledge of constructors, leading to higher code reusability.

We don't need any assumption on the element type (like being a monoid itself). At the same time the definition is not trivial (as (<|>) = const would be). It makes use of the list structure by pattern matching on the first argument.

The definition of <|> given above is associative and the empty list really is the empty element. We have

so all the laws you could ask for are satisfied (which is not true for list concatenation).

This instance is consistent with the one for Maybe: choice is biased to the left, yet when the left argument is unable to produce a value, the right argument takes over. The functions

are morphisms of alternatives (meaning psi x <|> psi y = psi (x <|> y) and psi x <*> psi y = psi (x <*> y)).

Edit: For the some/many methods I'd guess

应用函子在 Haskeller 中广为人知并深受喜爱，因为它们能够在有效的上下文中应用函数。

在范畴论术语中，可以证明 的方法Applicative：

等同于有一个Functor fwith 操作：

这个想法是写pure你只需用给定的值替换()in ，并将你的函数和参数压缩到一个元组中，然后在它上面映射一个合适的应用程序函数。unit(<*>)

此外，这种对应将这些Applicative定律转化为关于unit和的自然幺半群定律(**)，因此实际上应用函子正是范畴论者所说的松散幺半群函子（松散，因为(**)它只是一个自然变换而不是同构）。

好的，很好，很好。这是众所周知的。但这只是松散的单曲面函子的一个家族——那些尊重乘积的单曲面结构的函数。松散的幺半群函子在源和目标中涉及两种幺半群结构选择：如果将乘积转换为总和，您会得到以下结果：

通过唯一确定，将 sum 转换为其他幺半群结构似乎变得不那么有趣了unit :: Void -> f Void，所以你真的有更多的半群在进行。但仍然：

• 其他像上面这样的宽松单曲面函子是否研究过或有用？
• 有没有像他们一样的简洁的替代演示Applicative？

浏览 Haskell 的文档对我来说总是有点痛苦，因为你获得的关于一个函数的所有信息通常只是：f a -> f [a]这可能意味着任何数量的东西。

就像<|>函数的情况一样。

我得到的只是这个：(<|>) :: f a -> f a -> f a它是一个“关联二元运算” ......

经过检查，Control.Applicative我了解到它会根据实施情况做看似无关的事情。

好的，所以如果没有左则它返回右，否则它返回左，明白了.. 这让我相信它是一个“左或右”运算符，考虑到它使用|and|的历史用法为“或”，这有点道理"

除了这里它只是调用列表的连接运算符......打破我的想法......

那么这个功能到底是什么？它有什么用？它在宏伟的计划中处于什么位置？

考虑以下类型签名：

Foo现在我展示了从to类型optparse-applicative的自然转换Parser：

（好吧，它有点没用，但它会用于讨论）。

现在我将Bar成为免费的替代仿函数Foo：

鉴于这是一个自由函子，我应该能够从tomkParser进行自然转换：BarParser

事实上，这很有效，给了我一个Parser支持。然而，这是一个非常没用的，因为试图用它做很多事情会导致无限循环。例如，如果我尝试描述它：

并挂起直到被打断。

其原因似乎是在其定义中optparse-applicative 作弊manyand some：它在幕后使用单子解析。

我在这里做错了吗？鉴于此，我不明白如何以这种方式构造解析器。有任何想法吗？