问题标签 [applicative]

The user 'singpolyma' asked on reddit if there was some general structure underlying:

A free monad was suggested, but I wondered if this could be modeled more generally via applicative functors. In Abstracting with Applicatives, Bazerman shows us that the sum of two applicative functors is also an applicative functor, with bias to the left/right, provided we have a natural transformation in the direction of the bias. This sounds like it's what we need! Thus, I started my proposal, but then quickly ran into problems. Can anyone see solutions to these problems?:

---

Firstly, we start with the definition of the sum of two functors. I started here because we want to model sum types - either successes or successes and a failure.

And the two functors we want to work with are:

Success is straight forward - it's essentially Const [a]. However, Failure e I'm not so sure about. It's not an applicative functor, because pure doesn't have any definition. It is, however, an instance of Apply:

Next, we can define the sum of these functors, with a natural transformation from right to left (so a left bias):

And the only thing we now have to do is define our natural transformation, and this is where it all comes crumbling down.

The inability to create a Failure seems to be the problem. Furthermore, even being hacky and using ⊥ isn't an option, because this will be evaluated, in the case where you have InR (Success ...) <*> InL (Failure ...).

I feel like I'm missing something, but I have no idea what it is.

Can this be done?

假设我有一个函数（它没有任何实际应用，只是一种学术兴趣，因此用幺半群、应用函子和定点组合器编写它的方式很奇怪）

它会进行类型检查，但在我测试它之前，我不能确定它是否能达到预期的效果。

如何进行测试和/或调试呢？我的意思是在几次迭代后看到结果，就像使用take 10 [1..].

ghci我对like:break和的简单调试工具了解一些:step，但它会进入非终止计算，所以我无法检查任何东西（它甚至是有问题的^C）。而且我也不知道如何在这个函数中使用tracefrom模块。Debug

任何指针将不胜感激。

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

这个原子解析器单元：

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

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

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

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

我正在编写一个 xml-conduit 解析器，我更喜欢应用语法而不是 monadic。虽然有很多论据要结合，但我在应用中有些迷失了。我当前的问题是 8 个参数，我只想使用第 4 个和第 6 个来构造结果。

我可以使它工作的唯一方法是以下；不过，对于平面解决方案，应该有精美的星星排列：

有什么方法可以在没有括号的表格中做同样的事情？

假设 F 是具有附加定律的应用函子（使用 Haskell 语法）：

1. pure (const ()) <*> m === pure ()
2. pure (\a b -> (a, b)) <*> m <*> n === pure (\a b -> (b, a)) <*> n <*> m
3. pure (\a b -> (a, b)) <*> m <*> m === pure (\a -> (a, a)) <*> m

如果我们省略（3.），结构叫什么？

我在哪里可以找到有关这些法律/结构的更多信息？

评论评论

满足 (2.) 的函子通常称为可交换函子。

现在的问题是，（1.）是否暗示（2.）以及如何描述这些结构。我对满足 (1-2.) 但不满足 (3.) 的结构特别感兴趣

例子：

• 读者单子满足 (1-3.)
• 可交换幺半群上的 writer monad 仅满足 (2.)
• 下面给出的 monadF满足 (1-2.) 但不满足 (3.)

的定义F：

我们只导出类型X、、、、F和实例new。evalF

检查以下是否成立：

• liftM (const ()) m === return ()
• liftM2 (\a b -> (a, b)) m n===liftM2 (\a b -> (b, a)) n m

另一方面，liftM2 (,) new new不能替换为liftM (\a -> (a,a)) new：

评论 CA McCann 的回答

我有一个证明草图，证明 (1.) 暗示 (2.)

=

=

=

=

= ... =

= 见下文 =

= ... =

=

观察

对于缺失的部分，首先考虑

= ... =

= ... =

= ... =

= ... =

引理

我们使用以下引理：

暗示

我只能间接地证明这个引理。

缺失的部分

有了这个引理和第一个观察，我们可以证明

=

这是缺少的部分。

问题

这是否已经在某个地方得到证明（可能是广义的形式）？

评论

(1.) 暗示 (2.) 但否则 (1-3.) 是独立的。

为了证明这一点，我们还需要两个例子：

• 下面给出的 monadG满足 (3.) 但不满足 (1-2.)
• 下面给出的 monadG'满足 (2-3.) 但不满足 (1.)

的定义G：

我们只导出类型G、putTrue、getBool、evalG和Monad实例。

的定义G'与 的定义类似，但G有以下区别：

我们定义和导出execG：

我们不出口 getBool。

我的问题一方面是关于 Applicative 和 Monad 类型的类，另一方面是关于 Chomsky 层次结构的上下文无关和上下文敏感的语法级别。

我听说类型类和语法级别之间存在对应关系。这种对应关系有多准确？

也就是说，是否可以使用不比 Applicative 组合子更强的东西来解析所有上下文无关语法，并且是否所有可以使用不比 Applicative 组合子更强大的东西来解析的语法都是上下文无关的？换句话说，Applicative 类型类是否完全对应于上下文无关文法？

和同样的问题，除了用“上下文敏感”代替“上下文无关”和 Monad 应用。

---

赏金澄清： 类型类是否对应于语法级别？例如，是否有一组类型类提供表达式正则语言所需的所有操作，仅此而已？

这个问题的动机是我正在研究一个解析器，并且想根据我使用的组合器来确定我的实现处于哪个语法级别。这可能吗？

考虑一下我用来解决欧拉问题 58 的代码：

我不喜欢第二个函数中的模式匹配。它看起来比必要的复杂！这对我来说经常出现。这里，splitAt返回一个元组，所以我必须先解构它，然后才能递归。当我的递归本身返回一个我想要修改的元组时，同样的模式可能会更烦人。考虑：

与漂亮而简单的递归相比：

当然，这里的函数纯粹是胡说八道，可以用完全不同的更好的方式编写。但我的观点是，每当我需要通过递归返回多个值时，就会出现模式匹配的需求。

有什么方法可以避免这种情况，也许是通过使用Applicative或类似的方法？或者你会认为这种风格是惯用的吗？

我正在阅读一些 Haskell 教程并尝试熟悉该语言。我在 Monad/MonadPlus 教程中看到了这个例子：

我试图以无点风格重写它（只是作为一个练习，并不是说上面是错误的或非惯用的），但我卡住了：显然我可以编写一个自定义函数

然后使用

但我似乎从 LYAH 教程中记得，有一种方法可以使用函子或应用函子来构造计算树，最终可以输入参数以从“函子盒”中获取结果。但是我似乎无法在教程中找到示例。如何“巧妙”地改写上面的内容？

我一直在阅读Applicative Functors并且我很难调和类别理论和函数式编程各自术语中的不匹配。

虽然我浏览了各种博客，但我用于这项研究的最完整的资源是：

• McBride & Paterson -带效果的应用程序编程(PDF)
• Gibbons & Oliveira -迭代器模式的精髓(PDF)
• Tomas Petricek -在 LINQ 中编写成语

在范畴论中，函子是从源范畴到目标范畴（在范畴的范畴中）的态射。“category of categories”有一个包含源类别和目标类别的对象集合，以及一个包含以下内容的函子集合：源类别的恒等函子；目标类别的恒等函子；并且，连接源和目标的函子（如果源类别与目标类别相同，并且所讨论的函子是恒等式，则只需要一个函子）。

在函数式编程中，应用函子被描述为一对操作：

• pure : a -> f a
• <*> : f ( a -> b) -> f a -> f b.

这是我的问题

什么解释清楚了应用函子的函数式编程定义和函子的范畴理论定义之间的对应关系？

更具体地说，元组的哪些部分(pure,<*>)对应于：

1. 源类别
2. 目标类别
3. 函子所在的范畴
4. 函子对源类别对象的结构保持效果
5. 函子对源范畴态射的结构保持效应

笔记：我承认这可能是一个不完整的比喻，我提到的每个概念可能都没有一一对应的关系。我故意避免在这里分享我对明显对应关系的猜测，以保持我的问题简单并避免进一步混淆问题。

我读过这篇文章，但没有理解最后一节。

作者说 Monad 为我们提供了上下文敏感性，但仅使用 Applicative 实例也可以达到相同的结果：

没有 do-syntax 肯定会更丑陋，但除此之外，我不明白为什么我们需要 Monad。谁能帮我解决这个问题？