Talk:Monads/Maybe monad

From Rosetta Code
Revision as of 21:37, 4 February 2016 by Hout (talk | contribs)

Perhaps a specific task ?

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 ?

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)