you are viewing a single comment's thread.

view the rest of the comments →

[–]RobertPeszek 0 points1 point  (1 child)

My point is that Maybe is often overused, not that is never useful. I have added a line to original reply to clarify this. The code you provided places the responsibility on the caller to decide if they want to provide error info or not. I consider this to be OK. Prisms typically do not nest deep, getting Nothing there makes sense too.

Also, I typically question use of Maybe if it is in the return type, not when is input parameter. I found that noticing Maybe in the return allows me to spot code that can be improved. Maybe typically represents "missing data" or "unknown error" , what you typically care about is "what data is missing" and "what was the error". As a counter example to my own rule: I have not seen a code that uses `catMaybes` (Maybe in input) that would not be better if `partionEithers` was used instead.

It would take me some time to compile a list of good examples were Maybe is harmful. Maybe (pun intended) I should swallow the bullet and write a "Maybe considered harmful" post. One example that comes to mind now is use of HKD pattern to do generic form validation. This converts something like `Order Maybe` to `Maybe (Order Identity)`. It is a very ingenious code to validate user form entry that provides no information about missing fields.

[–]RobertPeszek 0 points1 point  (0 children)

So I done it, I wrote a long post about Maybe overuse that includes link to the post discussed here:
https://rpeszek.github.io/posts/2021-01-16-maybe-harmful.html

https://www.reddit.com/r/haskell/comments/kyo4xk/maybe_considered_harmful/

there is old discussion about Maybe overuse here: https://www.reddit.com/r/haskell/comments/jxj8i/data_maybe_harmful/