How to chain Result Monads using Monadex?

Fl4m3Ph03n1x

Background

In my quest to learn more about Monadex I am trying to chain a Result Monad several times in a function.
I understand this is achieved via the fmap, a function which takes a function and a Monad and returns a Monad.

defmodule TestMonadex do
  use Monad.Operators

  import Monad.Result

  # This wont work
  def p2(x) do
    x
    |> success()
    <|> (&plus_1/1)
    <|> (&plus_1/1) 
  end

  defp plus_1(n), do: n + 1
end

Problem

The problem here is that according to the documentation, Result Monad does not implement the fmap:

Question

Why can’t my example work?
How can I chain the Result Monad?

5 comments

#monads #chain #monadex

0 1440 5

2021-05-10 14:52:54 UTC

Showing Posts 1 to 5

Show Best Posts
Show All (oldest first)
Show All (newest first)

Sebb

isn’t fmap for functors while monads use bind?
(not sure, never used monads, Elixir gives me all I need (so far) with pattern matching, {:atom, value} and lists.)

Post #1

Fl4m3Ph03n1x

It is my current understanding that a Monad is a Functor and therefore should also implement this protocol.
(Not a pro on Monads also, still learning).

Post #2

dorgan

I wrote an explanation of fmap vs bind but then I realized the problem here is that for some reason the function needs to be in the left hand side of the <|> operator.
Functor.fmap takes a value and then a function: MonadEx/lib/functor.ex at master · rob-brown/MonadEx · GitHub
But <|> reverses the order: MonadEx/lib/monad/operators.ex at master · rob-brown/MonadEx · GitHub

So I think your function should do (&plus_1/1) <|> (&plus_1/1) <|> success(x) instead?

The explanation I started to write in case you want it:

The way to chain monads is by using bind, not fmap.
bind’s signature is bind :: m a -> (a -> m b) -> m b where m is the monad(the context). What this tells you is that you start with a monad m with a type a, you give it a function that works with an a and returns a monad m with a type mb, and bind will give you back that last m b.
To illustrate it a bit better, if I have a value x and I apply it a function a -> m b, like something that returns a Maybe b, and I want to apply that a -> m b again, I would end up with Maybe (Maybe b). bind lets you do composition while avoiding that nesting.

fmap on the other hand is a way to lift a function to work in a context. It’s signature is fmap :: (a -> b) -> (f a -> f b), which means that you start with a function from a to b and get back a lifted function that works in a context f(the functor). This is essentially what you do with Enum.map, you give it an list and it takes care of using the function in every element of the list and returns back a list. If you have a Maybe, fmap would lift the function to be applied to the element inside the Just but skip the Nothing.

Monads are indeed Functors in the sense that you can define fmap in terms of bind and return(the functions in that monadex module):

fmap f m = m >>= (return . f)

The other altenative is defining bind in terms of join and fmap.

The definition of fmap doesn’t involve monads though, it’s just a way to lift a function to work in a particular context.

An fmap definition for a result tuple would look like this:

def fmap({:ok, x}, f) do
  {:ok, f.(x)}
end
def fmap({:error, x}, _) do
  {:error, x}
end

While a definition of bind would looke like this:

def bind({:ok, x}, f) do
  f.(x)
end
def bind({:error, x}, _) do
  {:error, x}
end

Notice that in fmap we extract the x from the tuple so it can work with f (the a -> f a lifting), and then it wraps the result of applying f to x in an ok tuple again (the b -> f b lifting), essentially making the function f work in the context of a result tuple. But in bind the f already returns a result tuple, so we don’t need to wrap it, otherwise it would result in nested result tuples.

More “correct” definitions would be curried functions, though, so fmap would be:

def fmap(f), do: fn
  {:ok, x} -> {:ok, f.(x)}
  {:error, x} -> {:error, x}
end

So fmap here returns a version of f that can work with result tuples. I think this is a better illustration of what lifting a function means.

Post #3

Fl4m3Ph03n1x

Indeed if I reverse the order of things they work.
To me this feels quite counter intuitive.

This means I cannot pipe functions in their natural order of progression.
Am I missing something here?

Thanks @dorgan for the explanation, the examples with the tuples really did help!

Post #4

dorgan

I think this is correct.

I think the same, but I also think that the reason would be familiarity for functional programmers/mathematicians that are used to functional composition(which is essential to category theory).
If I have functions f and g, their composition g ∘ f (reads as g after f) could be visualized with this diagram:

     f             g
a───────────►b───────────►c
│                         ▲
└─────────────────────────┘
            g ∘ f

A lot of category theory constructs are built in this way, you have an a, a b and a c, you have an f that goes from a to b and a g that goes from b to c and you want to find the composition g ∘ f that goes directly from a to c. Note that the order of the operands of the composition is goes against the direction of the arrows, and I think that the order of operands in the <|> derives from this notation. If you look at it from this perspective, then it becomes the most intuitive/natural ordering, but I agree it’s hard to grasp at first.