exception,haskell,error-handling,monads,applicative

In your first example, you want to compose a function f :: a -> m a with itself. Let's pick a specific a and m for the sake of discussion: Int -> Maybe Int. Composing functions that can have errors Okay, so as you point out, you cannot just do...

My favorite example is the "purely applicative Either". We'll start by analyzing the base Monad instance for Either instance Monad (Either e) where return = Right Left e >>= _ = Left e Right a >>= f = f a This instance embeds a very natural short-circuiting notion: we proceed...

GHCi is a little bit peculiar. In particular, when you type an expression at the prompt, it tries to interpret it in two different ways, in order: As an IO action to execute. As a value to print out. Since IO is Applicative, it is interpreting pure A as an...

The Alternative type class provides the many combinator: class Applicative f => Alternative f where empty :: f a (<|>) :: f a -> f a -> f a many :: f a -> f [a] some :: f a -> f [a] some = some' many = many' many'...

You don't need to describe how to combine errors—that's taken care of by ValidationNel's applicative functor via the Semigroup instance for NonEmptyList. The argument to the applicative builder should instead indicate how to create people: def makePerson(name: String, age: Int, gender: Gender): Validation[NonEmptyList[InvalidPersonError], Person] = (validateName(name) |@| validateAge(age))(Person(_, _, gender))...

I don't really have a solution for the problem, but perhaps some intuition might help you to build applicative parsers more easily. When it comes to applicative, there are two kinds of "sequencing" that needs to be taken into consideration: The sequencing of the parsing operations: this is what determines...

Based on McBride and Paterson's laws for Monoidal(section 7) I'd suggest the following laws for liftA2 and pure. left and right identity liftA2 (\_ y -> y) (pure x) fy = fy liftA2 (\x _ -> x) fx (pure y) = fx associativity liftA2 id (liftA2 (\x y z ->...

parsing,haskell,monads,applicative,aeson

Essentially, you need a Parser [a] -> Parser NE.NonEmpty transformer, which is relatively easy: -- toNonEmptyP :: Parser [a] -> Parser NE.NonEmtpy toNonEmptyP p = fmap NE.nonEmpty p >>= maybe mzero return We map NE.nonEmpty on our regular list parser, which gives us Parser (Maybe NE.NonEmpty). We then inspect the...

fs <*> xs is more-or-less [f x | f <- fs, x <- xs]. Monads have the Applicative instance fM <*> xM = do f <- fM x <- xM return (f x) which corresponds to the list comprehension pretty directly....

syntactic-sugar,applicative,idris

I was able to get this working by taking care of two problems: if _ then _ else _ doesn't seem to propagate the idiom bracket to its subexpressions The default definition of if _ then _ else _ is (of course) lazy in its two branches, and Lazy' LazyEval...

haskell,functor,applicative,category-theory

The "neat alternative presentation" for Applicative is based on the following two equivalencies pure a = fmap (const a) unit unit = pure () ff <*> fa = fmap (\(f,a) -> f a) $ ff ** fa fa ** fb = pure (,) <*> fa <*> fb The trick to...

Firstly, note that both <$> and <*> associate to the left. There's nothing magical happening internally and we can see the transformation with essentially a series of eta expansions and beta reductions. Step-by-step, it looks like this: (((+) <$> (+3)) <*> (*100)) $ 5 -- Add parens ((fmap (+) (+3))...

haskell,syntax,infix-notation,applicative,infix-operator

Why is f <$> g <$> x equivalent to (f . g) <$> x ...well, this isn't so much a functor-thing as a Haskell-thing. The reason it works is that functions are functors. Both <$> operators work in different functors! f <$> g is in fact the same as...

scala,concurrency,monads,applicative

Well has soon has you have PairJob, you have what you need for applicative. With any generic type G, (here, that would be Job) if you have pairing: def pair[A,B](ga: G[A], gb: G[B]): G[(A,B)] (which for Job, is just PairJob(ga, gb)) and also map, then you can easily implement apply...

haskell,monads,functor,applicative

The easiest way would be with join: main = join $ parseArgs <$> getArgs <*> getStdGen Personally, I would prefer the form main = join $ liftM2 parseArgs getArgs getStdGen where join :: Monad m => m (m a) -> m a liftM2 :: Monad m => (a -> b...

a function that takes a (a -> a- > a) -> b function and an a as parameters and returns a b. This is correct. According to this reasoning , I should call this like : (<$>f) f 4 which would result in an Integer. No, because f does...

validation,scala,scalaz,applicative

This works: |@| result type is not ValidationNel (Applicative) but ApplicativeBuilder, you need yo apply it first to some function import scalaz._, Scalaz._ val x1: ValidationNel[String, Int] = 1.successNel val x2: ValidationNel[String, Int] = 2.successNel val x3: ValidationNel[String, Int] = 3.successNel println((x1 |@| x2 |@| x3)(_ + _ + _))...

<**> from Control.Applicative is flip <*>. Your example can work with that, slightly rearranged: >((+) <$> Just 3 <*> Just 5) <**> ((+) <$> Just 6) Just 14 ...

In general, "X is closed under Y" means that if you take some Xs and Y them, the result is an X. For example, "the set of integers is closed under addition" means that if you take two integers and add them, the result is an integer. Therefore, saying that...

haskell,monads,typeclass,functor,applicative

There's a lot of questions rolled into one here. But let's take them one at a time. First: why doesn't the compiler look at instance contexts when choosing which instance to use? This is to keep instance search efficient. If you require the compiler to consider only instances whose instance...

haskell,monads,applicative,fam-proposal

Well, I'm not terribly satisfied with the answers given so far, but I think the comments attached to them are a bit more compelling. So I'll summarize here: I think there's only one sensible Functor instance that follows from Applicative: fmap f fa = pure f <*> fa Assuming that's...

haskell,monads,functor,applicative,fam-proposal

With GHC 7.10 and above, you must implement Functor and Applicative. The class definitions for Monad mandate the superclass instances: class Functor f => Applicative f where ... class Applicative m => Monad m where ... Note that once you have a Monad instance, the Functor and Applicative instances can...

scala,validation,scalaz,applicative

There are lots of ways to write this, but I like the following: val checkX: X => Status[X] = x => isPositive(x.x1).tuple(isEven(x.x2)).as(x) Or: val checkX: X => Status[X] = x => isPositive(x.x1) *> isEven(x.x2) *> x.point[Status] The key point is that you want to run the two validations only for...

I believe there is a deeper reason. While it seems there is no canonical set of rules for Alternative, in order for Alternative to make sense, there definitely ought to be a relationship between Alternative and its Applicative operations (otherwise it'd be just an arbitrary monoid.) This answer to Confused...

haskell,monad-transformers,applicative

An implementation (taken from Tony Morris' functional programming course) could be (<*>) :: (Functor f, Monad f) => StateT s f (a -> b) -> StateT s f a -> StateT s f b StateT f <*> StateT a = StateT (\s -> (\(g, t) -> (\(z, u) -> (g...

I think Alt from the semigroupoids package comes closest to being a 'standard' typeclass. https://hackage.haskell.org/package/semigroupoids-5.0.0.1/docs/Data-Functor-Alt.html#t:Alt

Pretty much so for WrappedMonad. I guess it is becoming (and perhaps already was) essentially obsolete. But WrappedArrow is more difficult, because Arrow types and Applicative types have different kinds, * -> * -> * vs. * -> *. And because of the way GHC instance resolution works, adding the...

haskell,functional-programming,composition,functor,applicative

The Applicative class has the <*> operator (usually pronounced "ap", and is equivalent to Control.Monad.ap for most Monads), which combined with the <$> operator (itself just an infix alias for fmap) lets you write code like -- f :: a -> b -> c -- fa :: Applicative f =>...

(,) a is an Applicative when a is a Monoid. We can compose (,) (Sum Int) with other applicative using Data.Functor.Compose, and get an applicative that lets us estimate the "cost" assigned to a computation before running it. To count the steps, we need a lift function from the base...

Applicatives should satisfy the law point identity <*> v == v which yours does not since point identity List(1,2,3) == List(1) pure a for a zip list should return an infinite stream of a which is why you need a lazy data structure....

Applicative functor expressions are just function applications in the context of some functor. Hence: pure f <*> pure a <*> pure b <*> pure c -- is the same as: pure (f a b c) We want to prove that: pure (.) <*> u <*> v <*> w == u...

If you note that m (n _) is a monad transformer then you can define this operation. This is certainly the case when we notice that IO (Maybe a) is the same as MaybeT IO a: we then just use MaybeT's join. We can do this in no small part...

The types M and A are referenced from your def so they need to be part of the thing you're returning. I can't see any way to do this completely with the structural refinement, so I think you have to define a parametrized class; how about defining an implicit class...

The *> operator is defined, by default, as xs *> ys = id <$ xs <*> ys which in turn translates, by default, to const id <$> xs <*> ys That is, it replaces each element of xs with id to get xs' and then calculates xs' <*> ys. []...

scala,concurrency,functional-programming,future,applicative

None of the methods in other answers does the right thing in case of a future that fails quickly plus a future that succeeds after a long time. But such a method can be implemented manually: def smartSequence[A](futures: Seq[Future[A]]): Future[Seq[A]] = { val counter = new AtomicInteger(futures.size) val result =...

pure for zip lists repeats the value forever, so it's not possible to define a zippy applicative instance for Scala's List (or for anything like lists). Scalaz does provide a Zip tag for Stream and the appropriate zippy applicative instance, but as far as I know it's still pretty broken....

haskell,type-systems,applicative

The first argument of <*> is supposed to be f (a -> b). So given (<*>) (pure x), this is well-typed provided that x is some kind of function. The type of 2 is Num a => a. In other words, 2 can be any possible type, so long as...

Firstly, you need an instance of applicative for Option: implicit object AppOption extends Applicative[Option] { def map[A, B](f: A => B, o: Option[A]) = o.map(f) def unit[A](a: A): Option[A] = Some(a) def ap[A, B](of: Option[A => B], oa: Option[A]) = of match { case Some(f) => oa.map(f) case None =>...

scala,concurrency,functional-programming,applicative,haxl

How to implement getPageData assuming Fetch[A] is an Applicative ? All we need to do is drop the monadic bind >>= in favour of the applicative <*>. So instead of val getPageData = for { recent <- getRecent popular <- getPopular topics <- getTopics } yield (recent, popular, topics)...