Talk:Monads/Maybe monad: Difference between revisions
Content added Content deleted
Line 12: | Line 12: | ||
* useful things would entail a bit too much complexity (in the case of this particular monad) or 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 ? [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 20:37, 4 February 2016 (UTC) |
* there might be scope for framing these tasks more in terms of a class of '''problem''' than a class of solution ? [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 20:37, 4 February 2016 (UTC) |
||
: I agree - or, more specifically, I could accept either interpretation. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 21:14, 4 February 2016 (UTC) |
Revision as of 21:15, 4 February 2016
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:
- Create and compose safe versions (number -> Maybe number) of 3 partial functions (reciprocal, sqrt, log)
- 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: