5 ms·

Having offered this kindly explanation, would you say that this continues in the holy pursuit of a 'simple explanation' of what a monad is? Here's an intermedi

Having offered this kindly explanation, would you say that this continues in the holy pursuit of a 'simple explanation' of what a monad is? Here's an intermediate question triggered on your explanation: what is the byte level nature of your "monadification"? you say one has a function which converts a floating point to a "monad string", a string value to a "monad int" (a raven into a 'monad writing desk')? exactly what bytes characterize a "monad string" from a string? a "monad int" from a plain old int? it's perhaps a structure? maybe it has stack pointers among those structural elements?

efnx 11y ago
If 'm' is a monad then the difference between a 'String' and a 'm String' (monad string) is most likely just a constructor, but it's really up to that particular monad's implementation. It isn't a byte level difference, it's a context level difference. Constructors are very different in Haskell than (insert imperative Lang). They are much simpler. Monads are similarly simple but hard to explain without any familiarity with the language. I suggest you just dive in. The cool thing about Haskell is you don't have to understand everything in order to work with it.
im3w1l 11y ago
There are many monads, so the answer will depend on which one it is. For instance the "Maybe" monad I described in a sibling comment to yours could be implemented with a pointer that could be null, or not. Another Monad could be a Logger monad. "return" transform a value into a pair of a value and an empty log. So in this case a monad int could be implemented as a pair<int, string>. (bind would take a function that starts logging from scratch and make it a function that appends to a preexisting log).
tel 11y ago
It's really, really vital to note that "monad" is not a noun but an adjective. Your question thus has no answer as stated. Let's pick a type which happens to be monadic, though, like list. If `A` is a type and `List A` is the type of singly-linked lists with values in `A` then `fun a -> Cons a Nil` is what's sometimes called `return` and `flatten :: List (List A) -> List A` is what's sometimes called `join` and (List, return, join) is monadic. And anyway, the byte-structure of SLLs can vary from place to place, but any good implementation that works generically will do.
- im3w1l 11y ago
  I don't think you can define a monad in terms of just (return,join). (return,bind) works, or (fmap,join). EDIT: As a counterexample to uniqueness, consider fmap defined such that for all f and x, (fmap(f))(x)=[]. It is consistent with your return and join.
  - tel 11y ago
    Sorry, that's a good point. The triple formalism (T, mu, eta) already assumes T to be a functor, but I didn't state that explicitly! So you need (List, map, return, flatten) all of them.
  - tel 11y ago
    Also with your edit it's worth noting that your given fmap cannot be: it violates both functor laws. As it turns out, for Haskell and most datatype-like functors there is exactly one law abiding implementation of fmap implicit in the structure of the type.
    - im3w1l 11y ago
      Ah yes, you are right.
- theophrastus 11y ago
  Since you raised the linguistic characterization, (..'monad' is an adjective, not a noun, so your question doesn't apply), you'd therefore say there's "thus no answer" to the question: what's the difference between a "blue envelope" and a basic envelope? ('blue' being an adjective) In my experience, here's often what's lacking with teaching the latest in programming formalisms: folks need the new concepts explained in some terms of the old in order to understand them, (hence why i was trying to get someone to explain monads in terms of crusty old terms like (C) structures). The frustrating tendency always seems to be to concoct a host of new terms, and then to define them only among those unfamiliar terms; often giving well-intentioned detailed examples yet only using those novel terms and syntax. It would be akin to teaching a foreign language but not even trying to pick up a familiar object and point to it in association with saying the new term for it. By the bye, i accept and appreciate the explanation given somewhere here (likely by 'im3w1l'), that monadization generates a different structure for different incidences of monadification. This helps conceptualizing the mechanism, in a way that "binding of flattened functors returning null or non-null monads" doesn't. It's worthy to assume that we didn't all spring forth full grown out of the forehead of a particular computer science theory class. Nonetheless, the efforts are appreciated. Even given the root commenter here promised that monad was a "simple concept" with a simple definition. If you scan about this comment section, do you think this view is well supported?

efnx 11y ago

If 'm' is a monad then the difference between a 'String' and a 'm String' (monad string) is most likely just a constructor, but it's really up to that particular monad's implementation. It isn't a byte level difference, it's a context level difference. Constructors are very different in Haskell than (insert imperative Lang). They are much simpler. Monads are similarly simple but hard to explain without any familiarity with the language. I suggest you just dive in. The cool thing about Haskell is you don't have to understand everything in order to work with it.

im3w1l 11y ago

There are many monads, so the answer will depend on which one it is. For instance the "Maybe" monad I described in a sibling comment to yours could be implemented with a pointer that could be null, or not. Another Monad could be a Logger monad. "return" transform a value into a pair of a value and an empty log. So in this case a monad int could be implemented as a pair<int, string>. (bind would take a function that starts logging from scratch and make it a function that appends to a preexisting log).

tel 11y ago

It's really, really vital to note that "monad" is not a noun but an adjective. Your question thus has no answer as stated. Let's pick a type which happens to be monadic, though, like list. If `A` is a type and `List A` is the type of singly-linked lists with values in `A` then `fun a -> Cons a Nil` is what's sometimes called `return` and `flatten :: List (List A) -> List A` is what's sometimes called `join` and (List, return, join) is monadic. And anyway, the byte-structure of SLLs can vary from place to place, but any good implementation that works generically will do.

im3w1l 11y ago
I don't think you can define a monad in terms of just (return,join). (return,bind) works, or (fmap,join). EDIT: As a counterexample to uniqueness, consider fmap defined such that for all f and x, (fmap(f))(x)=[]. It is consistent with your return and join.
- tel 11y ago
  Sorry, that's a good point. The triple formalism (T, mu, eta) already assumes T to be a functor, but I didn't state that explicitly! So you need (List, map, return, flatten) all of them.
- tel 11y ago
  Also with your edit it's worth noting that your given fmap cannot be: it violates both functor laws. As it turns out, for Haskell and most datatype-like functors there is exactly one law abiding implementation of fmap implicit in the structure of the type.
  - im3w1l 11y ago
    Ah yes, you are right.
theophrastus 11y ago
Since you raised the linguistic characterization, (..'monad' is an adjective, not a noun, so your question doesn't apply), you'd therefore say there's "thus no answer" to the question: what's the difference between a "blue envelope" and a basic envelope? ('blue' being an adjective) In my experience, here's often what's lacking with teaching the latest in programming formalisms: folks need the new concepts explained in some terms of the old in order to understand them, (hence why i was trying to get someone to explain monads in terms of crusty old terms like (C) structures). The frustrating tendency always seems to be to concoct a host of new terms, and then to define them only among those unfamiliar terms; often giving well-intentioned detailed examples yet only using those novel terms and syntax. It would be akin to teaching a foreign language but not even trying to pick up a familiar object and point to it in association with saying the new term for it. By the bye, i accept and appreciate the explanation given somewhere here (likely by 'im3w1l'), that monadization generates a different structure for different incidences of monadification. This helps conceptualizing the mechanism, in a way that "binding of flattened functors returning null or non-null monads" doesn't. It's worthy to assume that we didn't all spring forth full grown out of the forehead of a particular computer science theory class. Nonetheless, the efforts are appreciated. Even given the root commenter here promised that monad was a "simple concept" with a simple definition. If you scan about this comment section, do you think this view is well supported?