applicative | 易学教程

Minimal Purely Applicative Parser

阅读更多关于 Minimal Purely Applicative Parser

问题 I'm trying to figure out how to build a "purely applicative parser" based on a simple parser implementation. The parser would not use monads in its implementation. I asked this question previously but mis-framed it so I'm trying again. Here is the basic type and its Functor , Applicative and Alternative implementations: newtype Parser a = Parser { parse :: String -> [(a,String)] } instance Functor Parser where fmap f (Parser cs) = Parser (\s -> [(f a, b) | (a, b) <- cs s]) instance

Applicative is to monad what X is to comonad

阅读更多关于 Applicative is to monad what X is to comonad

问题 Can we solve this equation for X ? Applicative is to monad what X is to comonad 回答1: After giving it some thought, I think this is actually a backward question. One might think that ComonadApply is to Comonad what Applicative is to Monad , but that is not the case. But to see this, let us use PureScript's typeclass hierarchy: class Functor f where fmap :: (a -> b) -> f a -> f b class Functor f => Apply f where apply :: f (a -> b) -> f a -> f b -- (<*>) class Apply f => Applicative f where

Applicative instance for MaybeT m assumes Monad m

阅读更多关于 Applicative instance for MaybeT m assumes Monad m

问题 I've been using the Haxl monad (described here: http://www.reddit.com/r/haskell/comments/1le4y5/the_haxl_project_at_facebook_slides_from_my_talk), which has the interesting feature that <*> for its Applicative instance isn't the same as ap from Control.Monad. This is a key feature that allows it to do concurrent computations without blocking. For example, if hf and ha are long computations, then let hf :: Haxl (a -> b) = ... ha :: Haxl a = ... in do f <- hf a <- ha return (f a) will do them

Why ZipList is not the default Applicative Instance for List

阅读更多关于 Why ZipList is not the default Applicative Instance for List

I am currently learning Applicatives in Haskell. If I am not wrong, there are two different Applicative instances for Lists, ( List and ZipList - the second being defined as a newtype wrapping a List value). The ZipList applicative instances seems more intuitive for me. It might be a dumb question, but is there a specific reason ZipList is not the default Applicative instance for Lists. pure (+) <*> [1,2,3] <*> [4,5,6] -- [5,6,7,6,7,8,7,8,9] pure (+) <*> ZipList [1,2,3] <*> ZipList [4,5,6] -- ZipList [5,7,9] Is it because the distributive version of Applicative List also happens to have a

How to show that a monad is a functor and an applicative functor?

阅读更多关于 How to show that a monad is a functor and an applicative functor?

问题 Monads are known to be theoretically a subset of functors and specifically applicative functors, even though it's not indicated in Haskell's type system. Knowing that, given a monad and basing on return and bind , how to: derive fmap , derive <*> ? 回答1: Well, fmap is just (a -> b) -> f a -> f b , i.e. we want to transform the monadic action's result with a pure function. That's easy to write with do notation: fmap f m = do a <- m return (f a) or, written "raw": fmap f m = m >>= \a -> return

How to transform Either[Future[A], Future[B]] to Future[Either[A, B]]

阅读更多关于 How to transform Either[Future[A], Future[B]] to Future[Either[A, B]]

I have an instance of Either[Future[A], Future[B]] and I would like to transform it to Future[Either[A, B]] . Since my previous question , cats 0.8.1 has been released, changing the structure of the library and dropping Xor in favor of Either , which is right-biased in 2.12. Thus the method described in the previous accepted answer does not work anymore. I have tried to find the appropriate imports but failed. cats.instances.either._ cats.implicits._ cats.syntax.bitraverse._ looked plausible but unfortunately does not work. Compilation still fails with value bisequence is not a member of

Resolving the type of `f = f (<*>) pure`

阅读更多关于 Resolving the type of `f = f () pure`

Recently I noticed that humourously liftA can be written as liftA (<*>) pure I thought this was neat and so as a bit of a joke I thought I would make a new "definition" of liftA based on this property: f = f (<*>) pure Now I had expected that this would be something of the same type as liftA that just never halted. However it fails to compile. • Occurs check: cannot construct the infinite type: t ~ (f (a -> b) -> f a -> f b) -> (a1 -> f1 a1) -> t • In the expression: f (<*>) pure In an equation for ‘f’: f = f (<*>) pure • Relevant bindings include f :: (f (a -> b) -> f a -> f b) -> (a1 -> f1

Computational cost of applicative style

阅读更多关于 Computational cost of applicative style

I am using a small database pool in my web app. And this particular function: withPool pool = bracket (takeConn pool) (putConn pool) can be rewritten in applicative style: withPool = bracket <$> takeConn <*> putConn Arguably it is just as readable and much more elegant. So naturally, I want to write it like that. But database connection pool supposed to be fast, and I am afraid that this style introduces unnecessary overhead. So my question is, how much overhead (if any) does use of applicative functors incur in Haskell? Are there any benchmarks? I really suspect they'll be compiled down to

Concurrent data access as in Haxl and Stitch

阅读更多关于 Concurrent data access as in Haxl and Stitch

问题 This is a follow-up to my previous question. As I understand from Haxl and Stitch they use a monad for data access. The monad is actually a tree of data access commands. The children are the commands the node depends on. The siblings are executed concurrently. The business logic creates the monad and then a separate function fetch interprets it. Now, the question: Suppose I am performing a few data access operations concurrently. I can use an applicative functor (not a monad), which is just a

Functors and Applicatives for types of kind (* -> ) ->

阅读更多关于 Functors and Applicatives for types of kind (* -> *) -> *

I ran into a situation where my code would benefit from using Functor and Applicative -like abstractions, but for types of kind (* -> *) -> * . Defining a higher-kinded functor can be done with RankNTypes like this class HFunctor f where hfmap :: (forall x. a x -> b x) -> f a -> f b But the higher kind version of Applicative is a bit trickier. This is the best I could come up with: class HFunctor f => HApplicative f where hpure :: (forall x. a x) -> f a (<**>) :: f (a :-> b) -> f a -> f b newtype (:->) a b x = HFunc (a x -> b x) infixr 5 :-> We need the :-> wrapper type in order to have