Monad Usage – Why Use ‘Return’ or ‘Unit’ Instead of ‘Lift’?

design-patternshaskellmonad

This is partly genuine curiosity, and partly a check on my understanding. I'm probably missing the point.

In Haskell, why does a monad use operations called return or unit to describe putting a type into the container — lifting it into the monadic space? It seems more intuitive to call the operation lift.

Right now, in my (probably incorrect) port of monads into my own project, I'm using (pseudocode):

MyThing.lift(x).bind(f)…

rather than

MyThing.unit(x).bind(f)…

because it's more intuitive for me to think of lifting x into the monadic space.

Is that wrong-headed? I keep getting burned by not thinking abstractly enough, and I suspect that's the case again.

Best Answer

The term unit comes from category theory where we define a monad as two natural transformations unit : Identity ~> m and join : m x m ~> m. In case you're curious, bind f = join . fmap f.

return comes from do notation where return looks appropriately algol-ish. It's actually debatable whether this was a good name since it tends to suggest that return is some sort of control flow instead of just being a plain old function.

We usually reserve lift for things that are more like a functor and lift whole functions or monads. lift :: m a -> t m a and liftM :: (a -> b) -> m a -> m b.

Related Solutions

Functional Programming – How Does the Maybe Monad Relate to the Option Type?

Reading the documentation on F#'s Option type, it looks like it does behave pretty much exactly like the Maybe type in Haskell, in that it can model either 'nothing' (None in F#, Nothing in Haskell), or a value of its argument type (Some in F#, Just in Haskell).

In Haskell, however, Maybe is also a monad, and the plumbing is such that it allows for calculations on Maybe values, early-returning Nothing if any of the variables in the calculation is Nothing. Used this way, Maybe is a simple error handler (or rather, error-ignoring device), and the fact that it is a monad allows moving the boilerplate out of the way. Look at this wikipedia article for a nice concise example. I don't think Option supports this kind of monadic usage (in fact, I'm wondering whether there is any explicit concept of a monad in F# at all). If you want this behavior in .NET, I guess you'd use Option.Value for all your arguments, and wrap the whole calculation in a try / catch on NullReferenceException.

So, while Option is similar to the Maybe type, it is not an equivalent to the Maybe monad.

Functional Programming – How to Use Error Monad with Validation in Monadic Functions

Fist I'd ask myself: Is having an invalid User a code bug or a situation that can normally occur (for example someone entering a wrong input to your application). If it's a bug, I'd try to ensure that it can never happen (like using smart constructors or creating more sophisticated types).

If it's a valid scenario then some error processing during runtime is appropriate. Then I'd ask: What does it really mean for me that a User is invalid?

Does it mean that an invalid User can make some code fail? Do parts of your code rely on the fact that a User is always valid?
Or does it just mean that its an inconsistency that needs to be fixed later, but doesn't break anything during the computation?

If it is 1., I'd definitely go for some kind of error monad (either standard or your own), otherwise you'll lose guarantees that your code is functioning properly.

Creating your own monad or using a stack of monad transformers is another issue, maybe this will be helpful: Has anyone ever encountered a Monad Transformer in the wild?.

Update: Looking at your expanded options:

Looks as the best way to go. Perhaps, to be really safe, I'd rather hide the constructor of User and instead export only a few functions that don't allow to create an invalid instance. This way you'll be sure that any time it happens it gets handled properly. For example, a generic function for creating a User could be something like
```
user :: ... -> Either YourErrorType User
-- more generic:
user :: (MonadError YourErrorType m) ... -> m User
-- Or if you actually don't need to differentiate errors:
user :: ... -> Maybe User
-- or more generic:
user :: (MonadPlus m) ... -> m User
-- etc.
```
Many libraries take a similar appropach, for example Map, Set or Seq hide the underlying implementation so that it's not possible to create a structure that doesn't obey their invariants.
If you postpone validation to the very end, and use Right ... everywhere, you don't need a monad any more. You can just do pure computations and resolve any possible errors at the end. IMHO this approach is very risky, as an invalid user value can lead to having invalid data elsewhere, because you didn't stop the computation soon enough. And, if it happens that some other method updates the user so that it's valid again, you'll end up with having invalid data somewhere and not even knowing about it.
There are several problems here.
- The most important is that a monad must accept any type parameter, not just User. So your validate would have to have type u -> ValidUser u without any restriction on u. So it's not possible to write such a monad that validates inputs of return, because return must be fully polymorhpic.
- Next, what I don't understand is that you match on case return u of in the definition of >>=. The main point of ValidUser should be to distinguish valid and invalid values, and so the monad must ensure that this is always true. So it could be simply
```
(>>=) (ValidUser u) f = f u
(>>=) (InvalidUser u) f = InvalidUser u
```
And this already looks very much like Either.

Generally, I'd use a custom monad only if

There are no existing monads that provide you with the functionality you need. Existing monads usually have many support functions, and more importantly, they have monad transformers so you can compose them into monad stacks.
Or if you need a monad that is too complex to describe as a monad stack.

Best Answer

Related Solutions

Functional Programming – How Does the Maybe Monad Relate to the Option Type?

Functional Programming – How to Use Error Monad with Validation in Monadic Functions

Related Topic