4 ms·

Agree that monads don't compose. I am not the OP, and not a Haskell programer, but my understanding is that Monad Transformers exist because Monads don't compo

Agree that monads don't compose. I am not the OP, and not a Haskell programer, but my understanding is that Monad Transformers exist because Monads don't compose, and when you want monadic effects to compose, you use Monad Transformers (the other option is a go crazy writing every combination and ordering of effects you want by hand). I got this impression from the papers I have read, particularly this one [1] Monad transformers offer an additional benefit to monadic programming: by providing a library of different monads and types and functions for combining these monads, it is possible to create custom monads simply by composing the necessary monad transformers. For example, if you need a monad with state and error handling, just take the StateT and ErrorT monad transformers and combine them. Notice the last line of the snippet I posted above. What am I missing? [1]: Monad Transformers Step by Step https://page.mi.fu-berlin.de/scravy/realworldhaskell/materialien/monad-transformers-step-by-step.pdf https://page.mi.fu-berlin.de/scravy/realworldhaskell/materia...

tathougies 9y ago
Monad transformers exist independent of the fact that monads don't compose. Can you explain what you mean by 'monad transformers exist because monads don't compose'? Are you saying the concept of a monad transformer wouldn't exist if monads did compose? This makes no sense, as there are applicative transformers despite the fact that you can compose applicatives freely.
- mavelikara 9y ago
  > Monad transformers exist independent of the fact that monads don't compose. Can you explain what you mean by 'monad transformers exist because monads don't compose'? I see what you mean. You are right - the concept of Monad Transformers exist independent of the fact that monads don't compose. What I meant was that MTs exist in Haskell programs because Monads don't compose. Of course, there probably exists a Haskell program where this is not the case, but I am certain MTs are largely used in Haskell because Monads don't compose. BTW, the grandparent is not the first to coin "MTs are .. use(d) to make monads compose" usage. The late Paul Hudak et al writes in [1] that: A ground-breaking attempt to better solve the overall problem began with Moggi’s proposal to use monads to structure denotational semantics. Wadler popularized Moggi’s ideas in the functional programming community by showing that many type constructors (such as List) were monads and how monads could be used in a variety of settings, many with an “imperative” feel (such as in Peyton Jones & Wadler). Wadler’s interpreter design, however, treats the interpreter monad as a monolithic structure which has to be reconstructed every time a new feature is added. More recently, Steele proposed pseudomonads as a way to compose monads and thus build up an interpreter from smaller parts, but he failed to properly incorporate important features such as an environment and store, and struggled with restrictions in the Haskell type system when trying to implement his ideas. In fact, pseudomonads are really just a special kind of monad transformer, first suggested by Moggi as a potential way to leave a “hole” in a monad for further extension. Notice the usage Steele proposed pseudomonads as a way to compose monads. So this usage has been established in the Haskell community at least from 1995. Why are you, presumably a Haskell programmer, surprised when someone repeated that usage in 2018 on an internet forum? [1]: Monad Transformers and Modular Interpreters (http://haskell.cs.yale.edu/wp-content/uploads/2011/02/POPL96-Modular-interpreters.pdf http://haskell.cs.yale.edu/wp-content/uploads/2011/02/POPL96...)
  - danharaj 9y ago
    > Notice the usage Steele proposed pseudomonads as a way to compose monads. So this usage has been established in the Haskell community at least from 1995. Why are you, presumably a Haskell programmer, surprised when someone repeated that usage in 2018 on an internet forum? Shockingly, our understanding of monads and monad transformers has advanced in the last 23 years.
  - mavelikara 9y ago
    > Shockingly, our understanding of monads and monad transformers has advanced in the last 23 years. @danharaj, of course! At least enough that when someone says "MTs exist to compose monads", to understand it as "MTs are used in Haskell programs to compose monadic effects".
  - tathougies 9y ago
    > Why are you, presumably a Haskell programmer, surprised when someone repeated that usage in 2018 on an internet forum? I hate the way monads in general are talked about in the Haskell community (I also do not like the language for other algebraic terms). In particular, it is common to say 'data type X is a monad'. This statement is completely nonsensical. A monad is a thing along with some operations. Haskell data is a concrete description of how to store a thing. By itself, a piece of data has no operations associated with it. There is no way a particular data type could be a monad, since a data type is just a thing. The proper terminology is 'X forms a monad along with these functions' or 'X has an instance for the Monad type class' (this is different, because the monad type class allows for a subset of monads, not general monads). I am on a personal mission to rid the Haskell world of sloppy language because it confuses beginners, in my opinion. For a long time, I thought monads were a thing. Then I realized they're just an algebraic structure, like groups or rings. When we say things like 'monads don't compose' it makes it seem like there is some deficiency in the idea of a monad that makes them not compose, rather than a realization that monad composition results in zero or more ways to combine two arbitrary monads. Thinking just the former makes you wonder if monads ought to be fixed. Realizing the latter means you realize that the lack of a fix indicates that putting two monads together can accomplish a variety of tasks, only one of which is likely suited to your use case.

tathougies 9y ago

Monad transformers exist independent of the fact that monads don't compose. Can you explain what you mean by 'monad transformers exist because monads don't compose'? Are you saying the concept of a monad transformer wouldn't exist if monads did compose? This makes no sense, as there are applicative transformers despite the fact that you can compose applicatives freely.

mavelikara 9y ago
> Monad transformers exist independent of the fact that monads don't compose. Can you explain what you mean by 'monad transformers exist because monads don't compose'? I see what you mean. You are right - the concept of Monad Transformers exist independent of the fact that monads don't compose. What I meant was that MTs exist in Haskell programs because Monads don't compose. Of course, there probably exists a Haskell program where this is not the case, but I am certain MTs are largely used in Haskell because Monads don't compose. BTW, the grandparent is not the first to coin "MTs are .. use(d) to make monads compose" usage. The late Paul Hudak et al writes in [1] that: A ground-breaking attempt to better solve the overall problem began with Moggi’s proposal to use monads to structure denotational semantics. Wadler popularized Moggi’s ideas in the functional programming community by showing that many type constructors (such as List) were monads and how monads could be used in a variety of settings, many with an “imperative” feel (such as in Peyton Jones & Wadler). Wadler’s interpreter design, however, treats the interpreter monad as a monolithic structure which has to be reconstructed every time a new feature is added. More recently, Steele proposed pseudomonads as a way to compose monads and thus build up an interpreter from smaller parts, but he failed to properly incorporate important features such as an environment and store, and struggled with restrictions in the Haskell type system when trying to implement his ideas. In fact, pseudomonads are really just a special kind of monad transformer, first suggested by Moggi as a potential way to leave a “hole” in a monad for further extension. Notice the usage Steele proposed pseudomonads as a way to compose monads. So this usage has been established in the Haskell community at least from 1995. Why are you, presumably a Haskell programmer, surprised when someone repeated that usage in 2018 on an internet forum? [1]: Monad Transformers and Modular Interpreters (http://haskell.cs.yale.edu/wp-content/uploads/2011/02/POPL96-Modular-interpreters.pdf http://haskell.cs.yale.edu/wp-content/uploads/2011/02/POPL96...)
- danharaj 9y ago
  > Notice the usage Steele proposed pseudomonads as a way to compose monads. So this usage has been established in the Haskell community at least from 1995. Why are you, presumably a Haskell programmer, surprised when someone repeated that usage in 2018 on an internet forum? Shockingly, our understanding of monads and monad transformers has advanced in the last 23 years.
- mavelikara 9y ago
  > Shockingly, our understanding of monads and monad transformers has advanced in the last 23 years. @danharaj, of course! At least enough that when someone says "MTs exist to compose monads", to understand it as "MTs are used in Haskell programs to compose monadic effects".
- tathougies 9y ago
  > Why are you, presumably a Haskell programmer, surprised when someone repeated that usage in 2018 on an internet forum? I hate the way monads in general are talked about in the Haskell community (I also do not like the language for other algebraic terms). In particular, it is common to say 'data type X is a monad'. This statement is completely nonsensical. A monad is a thing along with some operations. Haskell data is a concrete description of how to store a thing. By itself, a piece of data has no operations associated with it. There is no way a particular data type could be a monad, since a data type is just a thing. The proper terminology is 'X forms a monad along with these functions' or 'X has an instance for the Monad type class' (this is different, because the monad type class allows for a subset of monads, not general monads). I am on a personal mission to rid the Haskell world of sloppy language because it confuses beginners, in my opinion. For a long time, I thought monads were a thing. Then I realized they're just an algebraic structure, like groups or rings. When we say things like 'monads don't compose' it makes it seem like there is some deficiency in the idea of a monad that makes them not compose, rather than a realization that monad composition results in zero or more ways to combine two arbitrary monads. Thinking just the former makes you wonder if monads ought to be fixed. Realizing the latter means you realize that the lack of a fix indicates that putting two monads together can accomplish a variety of tasks, only one of which is likely suited to your use case.