“ap”有多么随意？单子实施？ [英] How arbitrary is the "ap" implementation for monads?

问题描述

我看到ap的两个实现：

pre> ap m1 m2 = do {f < - m1; x< - m2;返回（fx）}


和

  ap m1 m2 = do {x < -  m2; f <-m1;返回（fx）} 
  

第二个是不同的，但是它对于< code $

pure（。） < * GT; u * v * w = u * （v * w）

我尝试直观地理解monad的哪部分是应用函数。 ..

解决方案

1. 给定一个 Monad m 实例，它的必要规范是什么？ Applicative m 超类实例？ ：纯是 return ， *< ap ，所以

     mf< * GT; ms == do f < -  mf; s <-ms;返回（fs）
     






请注意，而不是 Applicative 类的法律。这是对 Monad s的要求，以确保一致的使用模式。






2. 鉴于该规范（通过候选实现），是 ap 唯一可接受的实现。 Answer ：令人震惊的是，否。类型>> = 所允许的值依赖性有时会导致执行效率低下：有些情况下<>< code>可以比 ap 更有效率，因为您不需要等待第一次计算完成，然后才能知道第二次计算是什么。

>满足 Applicative 法则，尽管它们不同意所需的 ap 实例？ 答案：是的。这个问题提出的倒退事例就是这样的事情。事实上，正如另一个回答所观察到的，任何应用都可以倒退，结果往往是不同的野兽。



对于读者的另一个例子和练习，请注意，非空列表是单数的，与普通列表相似。

  data Nellist x = x：&也许（Nellist x）
 
 necat :: Nellist x  - > Nellist x  - > Nellist x 
 necat（x：& Nothing）ys = x：&只需
 necat（x：& Just xs）ys = x：& Just（necat xs ys）
 
实例Monad Nellist其中
 return x = x：& （x：& Nothing）>> = k = kx 
（x：& Just xs）> = k = necat（kx）（xs>> = k）
  

至少查找 行为不同的符合适用法律的Applicative Nellist 。


I am currently studying the bonds between monad and applicative functors.

I see two implementation for ap:

ap m1 m2 = do { f <- m1 ; x <- m2 ; return (f x) }

and

ap m1 m2 = do { x <- m2 ; f <- m1 ; return (f x) }

The second one is different, yet, would it be a good implementation for <*> ?

I got lost in the proof of pure (.) <*> u <*> v <*> w = u <*> (v <*> w)

I try to get an intuition of "what part of the monad is the applicative functor"...

解决方案

There are at least three relevant aspects to this question.

1. Given a Monad m instance, what is the specification of its necessary Applicative m superclass instance? Answer: pure is return, <*> is ap, so

   mf <*> ms == do f <- mf; s <- ms; return (f s)
   

Note that this specification is not a law of the Applicative class. It's a requirement on Monads, to ensure consistent usage patterns.

2. Given that specification (by candidate implementation), is ap the only acceptable implementation. Answer: resoundingly, no. The value dependency permitted by the type of >>= can sometimes lead to inefficient execution: there are situations where <*> can be made more efficient than ap because you don't need to wait for the first computation to finish before you can tell what the second computation is. The "applicative do" notation exists exactly to exploit this possibility.

3. Do any other candidate instances for Applicative satisfy the Applicative laws, even though they disagree with the required ap instances? Answer: yes. The "backwards" instance proposed by the question is just such a thing. Indeed, as another answer observes, any applicative can be turned backwards, and the result is often a different beast.

For a further example and exercise for the reader, note that nonempty lists are monadic in the way familiar from ordinary lists.

  data Nellist x = x :& Maybe (Nellist x)

  necat :: Nellist x -> Nellist x -> Nellist x
  necat (x :& Nothing) ys = x :& Just ys
  necat (x :& Just xs) ys = x :& Just (necat xs ys)

  instance Monad Nellist where
    return x = x :& Nothing
    (x :& Nothing) >>= k = k x
    (x :& Just xs) >>= k = necat (k x) (xs >>= k)

Find at least four behaviourally distinct instances of Applicative Nellist which obey the applicative laws.

这篇关于“ap”有多么随意？单子实施？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！