Category talk:Monads: Difference between revisions
no edit summary
No edit summary |
|||
(2 intermediate revisions by one other user not shown) | |||
Line 38:
::::::::::::(1) While the general case algebraic data type is not monadic, I've yet to see an algebraic data type which cannot be used in a monad.
::::::::::::(2) Change of list length is roughly equivalent to a type change. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 21:29, 31 January 2016 (UTC)
:::::::::::::I think these issues may now be resolved by the edits, but FWIW, the problem with characterising monads by foregrounding algebraic datatypes was mainly one of emphasis. A monad is a category – a set of related morphisms or functions, if you like – it's not a datatype – and the simplest monad, in which the Return function is equivalent to the ID function [[wp:Monad_(functional_programming)#Identity_monad|(see under Identity Monad)]], involves no 'wrapper' or modal context at all. From the practical coding perspective, a monad is a pattern of function nesting, and the practical steps involved in creating that pattern consist of writing two functions. As you point out, a useful monad
::::::::::::::Ok, so why do you distinguish between list monad and maybe monad? More specifically, if I am working in a language where there's no enforced distinction between a list and a maybe (where the distinction comes from the supporting code - how the data gets used), it seems that I'd use identical implementations of <code>return</code> and <bind>. Do you disagree with this? If so, why do you say there's a problem with characterising monads by foregrounding algebraic datatypes? (If not, just let me know and I'll be happy.) --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 08:07, 3 February 2016 (UTC)
==Structure of Monads on Rosetta Code==
|