Talk:Monads/Maybe monad: Difference between revisions
→Monad Description: Defining Just and Nothing, for example, doesn't give us a monad.
(→Monad Description: The envelope is not the correspondence.) |
(→Monad Description: Defining Just and Nothing, for example, doesn't give us a monad.) |
||
Line 28:
::::If anything is missing, perhaps it is the element of *sequencing* these 'computations in a context' ? The *applicative* abstraction also involves computations embedded in some context, but in the applicative case each successive context-embedded computation is autonomous – without sequential dependencies. In contrast, the monadic bind unwraps, applies a supplied function which both computes and rewraps/re-embeds, and then allows the *next* 'computation in a context' to build on the value resulting from the predecessor. It's this possibility of allowing one embedded computation to depend on the outcome of another which is the distinguishing feature of monadic enchaining. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 22:22, 2 October 2019 (UTC)
::::PS another thing which might be worth tidying is the thematic clause – the opening proposition. The monad is not, of course, the type itself, but the wrapping and bind functions which enable monadic computations with that type. The envelope is not the correspondence. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 22:48, 2 October 2019 (UTC)
::::More concretely, defining Just and Nothing, Left and Right, or Lists, for example, gives us a type but does not give us a monad.
::::The monad instance for a type consists of well-formed monadic functions (bind, and return/pure) which enable monadic enchaining of computations *embedded in that type*. List is not a monad, nor are the Maybe or Either types in themselves. The List, Maybe and Either monads consists of the bind and return function instances written for each of those types. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 23:02, 2 October 2019 (UTC)
| |||