Category talk:Monads: Difference between revisions
no edit summary
(Moved Monads to Category:Monads) |
No edit summary |
||
| (6 intermediate revisions by 2 users 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 is very likely to involve some kind of modal wrapper (though even the identity monad is used in programming), but while that may be an empirically (though not formally) *almost* necessary condition, it is neither practically sufficient, nor conceptually central enough to provide an adequate substitute for foregrounding the monadic functions themselves, and the value of the function nesting which they enable. (In my personal view :-) [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 17:42, 2 February 2016 (UTC)
::::::::::::::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==
Line 43 ⟶ 45:
Perhaps we should use the overall structure used for [http://rosettacode.org/wiki/Category:Sorting_Algorithms Sorting Algorithms]. That is, make [http://rosettacode.org/wiki/Monads Monads] redirect to [http://rosettacode.org/wiki/Category:Monads Category:Monads], which lists all Monads, and then, e.g. the List Monad, make [http://rosettacode.org/wiki/List_monad List_monad] redirect to [http://rosettacode.org/wiki/Monads/List_monad Monads/List_monad] in the same way that [http://rosettacode.org/wiki/Merge_sort Merge_sort] redirects to [http://rosettacode.org/wiki/Sorting_algorithms/Merge_sort Sorting_algorithms/Merge_sort]. This way it fits an existing structure on the site, and it makes it clear that there are many different kinds of Monads. Plus, each kind of Monad can have a task tailored to its semantics. Any thoughts? [[User:Domgetter|Domgetter]] ([[User talk:Domgetter|talk]]) 09:25, 31 January 2016 (UTC)
: Yes, I agree – I think that would work better [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 09:37, 31 January 2016 (UTC)
:: Looks like that turned out nicely. It feels much more organized and uncluttered. [[User:Domgetter|Domgetter]] ([[User talk:Domgetter|talk]]) 08:52, 1 February 2016 (UTC)
::: Good. A useful category to introduce, I think. Perhaps a 3rd entry ? The Writer monad is useful, and quite easily understood and written - maybe worth adding, for further comparison across languages [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 19:58, 1 February 2016 (UTC)
| |||