Hacker News Reader

Comment by dahart | Hacker News Reader

So, the only problem here is none of the examples actually handle the errors. Chains of partial functions, using any language I've ever tried, are easy when you don't have to do anything about the null value. The article demonstrates this in multiple languages. In practice, the hell only starts when you have to send control flow somewhere else or show the user a different response for every failed partial. I haven't used monads intentionally, can they do anything special about the real world case of having to handle every error separately?

View on HN

People would use something like an Either monad in that case (in real code they may use an Error monad). If all your getData functions have a return type `Either MyError GoodResult` then you could write something like:

  data MyError = MyFirstError | MySecondError

  type GoodResult = String

  myFunc = 
    case doEither of
      Right x -> *handle good result*
      Left MyFirstError -> *handle error*
      Left MySecondError -> *handle error*
    where 
      doEither = do
        a <- getData
        b <- getMoreData a
        c <- getMoreData b
        d <- getEvenMoreData a c
        return d

If one of those functions returns a "Left" (or error) value, the remaining functions are not evaluated. If they all return a "Right" value, doEither evaluates to a successful "Right" value.

This works much better when all of your functions fail in the same way. If some functions fail with an empty Maybe and some fail with an Either and some with Error you will have to wrap all of those to take advantage of do-notation.

> If some functions fail with an empty Maybe and some fail with an Either and some with Error you will have to wrap all of those

While this is true, the wrapping can be quite simple. Turning a Maybe into an Either is just a `fromMaybe (Left MyErr) Right`, and you can of course give it a name to clean it up even more.

That particular function is tied to Maybe and Either. Good luck with that when your functions start returning all types of different monads and welcome to monad transformer hell.

Maybe and Either was the topic of discussion. If you want to discuss a different example, present a different example.

Attempting to speak usefully to vague generality... if your functions are returning different concrete monadic values you need to either run them and get something pure out or translate them into your current context. It's usually better practice, however, to leave the choice of monad up to the call site and only ask for the interfaces you need (MonadState, MonadReader, etc), at which point there's no call-site-local translation needed at all, you just have to make sure you're supporting the interfaces requested.

Please don't use Either to carry errors, it's really silly to use a language with a strong type system and then rely on convention to represent the error on the correct side of the monad.

Is error left or right again?

That's right, you shouldn't have to remember.

Use a more specific type for this, some GADT with clearly named instances (e.g. "Error" and "Value").

Right is the right result and Left is the wrong result. That's about as easy it gets when it comes to remembering things. There is already a strong convention for using Either for this purpose and it's built into the standard library, since the Monad instance is designed to allow you to do this.

If you create your own data type for this, you are designing yourself into the Monad transformer hell you mention in another comment.

> That's about as easy it gets when it comes to remembering things

I use a statically typed language so I have fewer things to remember because the compiler does the bookkeeping for me.

`Either` is a generic variant record, it should not be used to carry errors.

And as a general rule, any programming construct that relies on convention instead of static typing is prone to generating bugs.

To be fair, this is more relying on a pun than it is convention.

I don't think this changes your point, though.

> `Either` is a generic variant record, it should not be used to carry errors.

The name suggests that, but the Monad instance suggests that Either is an asymmetric data type, where the left and right branches carry different meaning.

> And as a general rule, any programming construct that relies on convention instead of static typing is prone to generating bugs.

If the Either branches were named `Error` and `Success`, using `Error` to carry errors would be just as much of a convention as using `Left` for that purpose (a more sensible convention, but nonetheless a convention). The only way you'd get around that is if you'd somehow encode in the language what is and what isn't an error and use that to statically force correct branch usage.

I agree that would be a good convention to move away from - I don't think it takes a GADT, though; a regular data type should be fine.

For my part I think we should also deprecate the Functor (and dependent) instances for Either and tuple - but I know there are some who strongly disagree and I don't care all that much.

You can. Instead of passing null through the chain you could pass an actual error object.

Check out Elixir With statements for example: http://openmymind.net/Elixirs-With-Statement/

We do something similar in ruby with deterministic gem. Each action returns Success(value) or Failure(error). The error object is one of our own defined error instances (e.g. Responses::Unauthorized.new(msg)). These are then translated to actual error codes and messages in the web layer.

We added something similar to do-notion for ruby in deterministic gem. Not very nice but makes using deterministic a bit more convenient. https://github.com/pzol/deterministic#chaining-with-in_seque...

Reply on news.ycombinator.com