适用于Haskell [英] ApplicativeDo in Haskell

问题描述

AFAIK是GHC8的新增功能之一，是ApplicativeDo语言扩展，如果可能的话，它将对相应的Applicative方法(<$>，<*>)的do表示减掉.我有以下问题.

AFAIK one of the new additions to GHC8 is the ApplicativeDo language extension, which desugars the do-notation to the corresponding Applicative methods (<$>, <*>) if possible. I have the following questions.

如何确定对Applicative方法的废除是否可行?据我所知，它会进行依赖性检查(如果后者取决于前者的结果)来确定资格.还有其他条件吗?

How does it decide whether the desugaring to Applicative methods is possible? From what I know, it does a dependency check (if the later depends on the result of former) to decide the eligibility. Are there any other criteria?

尽管此添加使没有任何Monad实例的类(可能是?)的应用代码更易于阅读.但是对于同时具有Monad和Applicative实例的结构:从可读性角度来看，这是推荐的做法吗?还有其他好处吗?

Although this addition makes applicative code easier to read for classes that don't have any Monad instance (maybe ?). But for structures that both have a Monad and an Applicative instance: Is this a recommended practice (from the readability perspective)? Are there any other benefits?

推荐答案

如何确定对Applicative方法的废除是否可行?据我所知，它会进行依赖性检查(如果后者取决于前者的结果)来确定资格.还有其他条件吗?

How does it decide whether the desugaring to Applicative methods is possible? From what I know, it does a dependency check (if the later depends on the result of former) to decide the eligibility. Are there any other criteria?

论文和跟踪页面是最好的信息来源.一些要点:

The paper and trac page are the best sources of information. Some points:

• ApplicativeDo尽可能使用应用程序-包括在某些情况下仅将do块的一部分应用的情况下将它们与>>=混合
• 构造了一种有向依存关系图，以查看哪些部分可以并行化"
• 有时此图没有明显的最佳翻译！在这种情况下，GHC会选择(大致来说)本地最小的翻译

• ApplicativeDo uses applicatives wherever possible - including mixing them with >>= in some cases where only part of the do block is applicative
• A sort of directed graph of dependencies is constructed to see which parts can be "parallelized"
• Sometimes there is no obvious best translation of this graph! In this case, GHC chooses the translation that is (roughly speaking) locally smallest

尽管此添加使没有任何Monad实例的类(也许是?)的应用代码更易于阅读.但是对于同时具有Monad和Applicative实例的结构:是否建议这样做(从可读性的角度来看)?还有其他好处吗?

Although this addition makes applicative code easier to read for classes that don't have any Monad instance (maybe ?). But for structures that both have a Monad and an Applicative instance: Is this a recommended practice (from the readability perspective)? Are there any other benefits?

这是有关Applicative和Monad之间差异的答案.直接引用:

Here is an answer about the difference between Applicative and Monad. To quote directly:

要部署<*>，请选择两个计算，一个函数一个，另一个参数，然后将它们的值由应用程序合并.要部署>>=，请选择一个计算，然后说明如何利用其结果值选择下一个计算.这是批处理模式"和交互式"操作之间的区别.

To deploy <*>, you choose two computations, one of a function, the other of an argument, then their values are combined by application. To deploy >>=, you choose one computation, and you explain how you will make use of its resulting values to choose the next computation. It is the difference between "batch mode" and "interactive" operation.

这类事情的主要示例是

A prime example of this sort of thing is the Haxl monad (designed by Facebook) which is all about fetching data from some external source. Using Applicative, these requests can happen in parallel while Monad forces the requests to be sequential. In fact, this example is what motivated Simon Marlow at Facebook to make the ApplicativeDo extension in the first place and write the quoted paper about it.

通常，大多数Monad实例不一定从Applicative中受益.根据我在上面引用的相同答案:

In general, most Monad instances don't necessarily benefit from Applicative. From the same answer I quoted above:

我很欣赏ApplicativeDo是使应用程序更加实用(在某些情况下意味着更快)的一种好方法，这些程序以单子形式编写，而您没有时间进行重构.但是否则，我会争辩说，当您必须但单调时，也必须是了解发生情况的更好方法.

I appreciate that ApplicativeDo is a great way to make more applicative (and in some cases that means faster) programs that were written in monadic style that you haven't the time to refactor. But otherwise, I'd argue applicative-when-you-can-but-monadic-when-you-must is also the better way to see what's going on.

所以:在可能的情况下，在Monad上使用Applicative，并在与相关的应用表达式相比确实更好(例如在某些情况下必须在Facebook上写)的情况下利用ApplicativeDo.

So: use Applicative over Monad when possible, and exploit ApplicativeDo when it really is nicer to write (like it must have been in some cases at Facebook) than the corresponding applicative expression.

这篇关于适用于Haskell的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！