[aaronblohowiak]

>That pattern just turns out to be very useful.

Like NaN, it can be hard to track down where things went wrong.

[masklinn]

Except contrary to NaN, the type system encodes where it can exist and what its span is.

[dllthomas]

Right, you can rule out the pieces that are typed as "NaN-free" - hopefully that's a lot.

This is a great reason to avoid huge chunks of code stitched together staying inside Maybe, while still being convenient on the small scale.

[dllthomas]

But that's precisely why you abstract it; so you can switch to Error in need be...

[mokus]

> Like NaN, it can be hard to track down where things went wrong.

Unlike NaN, you have the freedom to not use it when you don't want it.

[Tyr42]

So, Either String a <=> Maybe a, but with a nice reason something went wrong.

[mercurial]

Not quite. They are not restricted to error handling. You can have methods returning a Maybe something without it being an error (just like there are plenty of valid reasons for returning null instead of throwing an exception). You can also use Maybe in a data structure:

  data Employee = Employee { name : Text, spouse : Maybe Text }

You may also want to use Either to store two possible outcomes of an operation, though I would recommend using your own sum type for clarity:

  data MyOwnEither a b = MyLeft a | MyRight b

[Evbn]

If Nothing is ever an error, than you can add code to handle that case. It isn't really different from some method returning an empty list and other functions being basically no-ops afterward.