My implementation of formlets, based on the original paper, composes quite a few applicative functors. They're all standard applicatives. For example, the one that looks up values from the submitted form is just a specialized Reader (i.e. a Reader with one of the type parameters fixed to the form type). The applicative responsible for generating form element names is a State. Another two of the applicatives are actually the same applicative, only specialized with different type parameters.
Since many of these are already implemented in FSharpx, I decided to use those implementations instead... After making the necessary changes and getting it to compile, I ran the tests and got a lot of failures. Many of the outputs involving lists were exactly in inverse order! I traced it down to the composition of applicatives, but I couldn't figure out what was wrong.
I'll illustrate with a simple but concrete example. We'll use the Writer applicative. Essentially, the effect of this applicative is appending values with a monoid. Here we'll just accumulate on a list.
This is much simpler to see in code:
let puree x = [],x let ap (x1,x2) (f1,f2) = f1 @ x1, f2 x2
An example using it:
puree (-) |> ap (["a";"b"],3) |> ap (["c";"d"],2)
This evaluates to (["a"; "b"; "c"; "d"], 1) , i.e. it concatenates the lists (the effect) and applies the function to the second value in the tuple.
So far so good. Now let's try to compose this applicative with itself. Composing applicatives is easy: as I explained in a previous article, just lift ap and apply pure to pure:
let lift2 f a b = puree f |> ap a |> ap b let composedPure x = x |> puree |> puree let composedAp x f = lift2 ap x f
Let's see how this works:
composedPure (-) |> composedAp (["a"; "b"], ([1; 2], 2)) |> composedAp (["c"; "d"], ([3; 4], 3))
which gives us (["c"; "d"; "a"; "b"], ([1; 2; 3; 4], -1))
Uh oh, the outer applicative has its effect flipped! The result should have been (["a"; "b"; "c"; "d"], ([1; 2; 3; 4], -1)) . What went wrong here?
One difference in this code with the Haskell definition of applicative functors is that I flipped the parameters of ap. This allowed us to apply ap with a pipe as is usual in F#. You could also use a forward and a backward pipe to "infixify" a function but it just doesn't look right to me. Even though it compiles and apparently looks correct, this difference broke our applicative composition.
In order to fix the applicative composition and still keep the convenient flipped parameters, we have to change composedAp to:
let flip f a b = f b a let composedAp x f = flip (lift2 (flip ap)) x f
The question now is: do you really understand why this composedAp is correct, just by looking at its definition, while the previous one would flip one of the applicatives and not the other?
To be honest, I don't. But simple equational reasoning can tell us what went wrong. Let's start with the original (incorrect) definition of composedAp:
lift2 ap x f = puree ap |> ap x |> ap f // lift2 definition = ap f (ap x (puree ap)) // |> definition = ap (f1,f2) (ap (x1,x2) (pap1, pap2)) // expand tuples, apply puree = ap (f1,f2) (pap1 @ x1, pap2 x2) // apply inner ap = pap1 @ x1 @ f1, pap2 x2 f2 // apply outer ap = [] @ x1 @ f1, ap x2 f2 // apply puree = x1 @ f1, ap (x21, x22) (f21, f22) // simplify empty list, expand tuples = x1 @ f1, (f21 @ x21, f22 x22) // apply ap
Now the correct composedAp, for comparison:
flip (lift2 (flip ap)) x f = flip (fun f a b -> ap b (ap a (puree (flip ap)))) x f // lift2 definition = (fun f a b -> ap b (ap a (puree (flip ap)))) f x // apply flip = ap x (ap f (puree (flip ap))) // apply lambda = ap (x1,x2) (ap (f1,f2) (pfap1, pfap2)) // expand tuples, apply puree = ap (x1,x2) (pfap1 @ f1, pfap2 f2) // apply ap = pfap1 @ f1 @ x1, pfap2 f2 x2 // apply ap = [] @ f1 @ x1, (flip ap) f2 x2 // puree = f1 @ x1, ap x2 f2 // simplify empty list, apply flip = f1 @ x1, ap (x21, x22) (f21, f22) // expand tuples = f1 @ x1, (f21 @ x21, f22 x22) // apply ap
By comparing both you can get a better understanding of why two flips are necessary.
Reasoning like this is a simple but powerful tool. We kinda do it continuously, informally, while writing code, which is usually called "running the program in your head". The absence of side-effects (i.e. pure functional programming) makes it easier to do it formally as well as informally, since you typically need to juggle less stuff in your head.