Talk:Monads/Maybe monad

From Rosetta Code

Perhaps a specific task ?[edit]

It can help comparison across languages if there is a specific task with a readily intelligible motivation. Providing a specific set of inputs and expected outputs can make the code even more directly comparable.

One candidate might be to:

  1. Create and compose safe versions (number -> Maybe number) of 3 partial functions (reciprocal, sqrt, log)
  2. Show the results of applying the required composition to a specific set of input values. In the ES5 JavaScript example, I have used, for instance [-2, -1, -0.5, 0, 1 / Math.E, 1, 2, Math.E, 3, 4, 5]

Languages to which a Maybe monad is less relevant ?[edit]

Interesting comment on the difficulty of finding something useful for J. I'm not sure whether the implication is that:

  • useful things would entail a bit too much complexity (in the case of this particular monad) or that
  • there might be scope for framing these tasks more in terms of a class of problem than a class of solution ? Hout (talk) 20:37, 4 February 2016 (UTC)
I agree - or, more specifically, I could accept either interpretation. --Rdm (talk) 21:14, 4 February 2016 (UTC)
I suppose I see the deeper problem as the tension between structure (often nested) and sequence (often threading more than one strand of data). Not sure if that resonates with the J case. Does J have a more natural way of avoiding/handling exceptions when a input somewhere inside a function nest is out of range ? (or is 'function nest' perhaps a less relevant form of structure in the array model ?) Hout (talk) 21:37, 4 February 2016 (UTC)
This is a real tension in J:
"Exceptions" either cancel processing, meaning no result array, or they must be avoided. If they are avoided, then you need some value in the result for that case. So there's been some extensive work done, within the language, to implement best effort consistent results for exceptional cases where that seems to make sense (and, of course, to generate errors for the nonsensical cases).
Also, the language does have try/catch mechanisms, but usually best practice is to instead to use preconditions, to normalize the data, or so on. Exception are usually best thought of as a sign of a problem with the code rather than a sign of a problem with the data. --Rdm (talk) 21:56, 4 February 2016 (UTC)