What are practical uses of applicative style?

Question

I am a Scala programmer, learning Haskell now. It\'s easy to find practical use cases and real world examples for OO concepts, such as decorators, strategy pattern etc. Books an

Answer 1

I finally understood how applicatives can help in day-to-day programming with that presentation:

https://web.archive.org/web/20100818221025/http://applicative-errors-scala.googlecode.com/svn/artifacts/0.6/chunk-html/index.html

The autor shows how applicatives can help for combining validations and handling failures.

The presentation is in Scala, but the author also provides the full code example for Haskell, Java and C#.

Answer 2

There are some ADTs like ZipList that can have applicative instances, but not monadic instances. This was a very helpful example for me when understanding the difference between applicatives and monads. Since so many applicatives are also monads, it's easy to not see the difference between the two without a concrete example like ZipList.

Answer 3

Applicatives are great when you've got a plain old function of several variables, and you have the arguments but they're wrapped up in some kind of context. For instance, you have the plain old concatenate function (++) but you want to apply it to 2 strings which were acquired through I/O. Then the fact that IO is an applicative functor comes to the rescue:

Prelude Control.Applicative> (++) <$> getLine <*> getLine
hi
there
"hithere"

Even though you explicitly asked for non-Maybe examples, it seems like a great use case to me, so I'll give an example. You have a regular function of several variables, but you don't know if you have all the values you need (some of them may have failed to compute, yielding Nothing). So essentially because you have "partial values", you want to turn your function into a partial function, which is undefined if any of its inputs is undefined. Then

Prelude Control.Applicative> (+) <$> Just 3 <*> Just 5
Just 8

but

Prelude Control.Applicative> (+) <$> Just 3 <*> Nothing
Nothing

which is exactly what you want.

The basic idea is that you're "lifting" a regular function into a context where it can be applied to as many arguments as you like. The extra power of Applicative over just a basic Functor is that it can lift functions of arbitrary arity, whereas fmap can only lift a unary function.

Answer 4

Here is an example taken from the aeson package:

data Coord = Coord { x :: Double, y :: Double }

instance FromJSON Coord where
   parseJSON (Object v) = 
      Coord <$>
        v .: "x" <*>
        v .: "y"

Answer 5

I described an example of practical use of the applicative functor in a discussion, which I quote below.

Note the code examples are pseudo-code for my hypothetical language which would hide the type classes in a conceptual form of subtyping, so if you see a method call for apply just translate into your type class model, e.g. <*> in Scalaz or Haskell.

If we mark elements of an array or hashmap with null or none to indicate their index or key is valid yet valueless, the Applicative enables without any boilerplate skipping the valueless elements while applying operations to the elements that have a value. And more importantly it can automatically handle any Wrapped semantics that are unknown a priori, i.e. operations on T over Hashmap[Wrapped[T]] (any over any level of composition, e.g. Hashmap[Wrapped[Wrapped2[T]]] because applicative is composable but monad is not).

I can already picture how it will make my code easier to understand. I can focus on the semantics, not on all the cruft to get me there and my semantics will be open under extension of Wrapped whereas all your example code isn’t.

Significantly, I forgot to point out before that your prior examples do not emulate the return value of the Applicative, which will be a List, not a Nullable, Option, or Maybe. So even my attempts to repair your examples were not emulating Applicative.apply.

Remember the functionToApply is the input to the Applicative.apply, so the container maintains control.

list1.apply( list2.apply( ... listN.apply( List.lift(functionToApply) ) ... ) )

Equivalently.

list1.apply( list2.apply( ... listN.map(functionToApply) ... ) )

And my proposed syntactical sugar which the compiler would translate to the above.

funcToApply(list1, list2, ... list N)

It is useful to read that interactive discussion, because I can't copy it all here. I expect that url to not break, given who the owner of that blog is. For example, I quote from further down the discussion.

the conflation of out-of-statement control flow with assignment is probably not desired by most programmers

Applicative.apply is for generalizing the partial application of functions to parameterized types (a.k.a. generics) at any level of nesting (composition) of the type parameter. This is all about making more generalized composition possible. The generality can’t be accomplished by pulling it outside the completed evaluation (i.e. return value) of the function, analogous to the onion can’t be peeled from the inside-out.

Thus it isn’t conflation, it is a new degree-of-freedom that is not currently available to you. Per our discussion up thread, this is why you must throw exceptions or stored them in a global variable, because your language doesn’t have this degree-of-freedom. And that is not the only application of these category theory functors (expounded in my comment in moderator queue).

I provided a link to an example abstracting validation in Scala, F#, and C#, which is currently stuck in moderator queue. Compare the obnoxious C# version of the code. And the reason is because the C# is not generalized. I intuitively expect that C# case-specific boilerplate will explode geometrically as the program grows.