4 ms·

> monad transformers (the promise of aspect oriented programming actually realized) I hardly see any overlap between these two concepts. AOP is about cross c

> monad transformers (the promise of aspect oriented programming actually realized) I hardly see any overlap between these two concepts. AOP is about cross cutting concerns and being able easily insert similar functionalities in unrelated areas of the code. Monad transformers are the hack you need to use to make monads compose.

danharaj 9y ago
Monad transformers are distinct from monad composition, it just seems like they're the same because a monad transformer takes the Identity monad to some other monad. The correct conceptualization of monad composition is a distributive law called as such because it generalizes distributive laws from algebra. Of course the two are related. Monad transformers allow one to slice up the functionality and concerns of a program in a dimension different from slicing of a program into components that are then composed together; e.g. a bunch of functions that call each other or a bunch of objects that pass messages between themselves. Each monad transformer in a transformer stack adds functionality and concerns that the other parts of the stack don't need to care about. Components can then be written polymorphically in the concerns they care about allowing them to be instantiated wherever the capabilities they need are present. Ultimately a program is instantiated to a particular transformer stack and then it is supplied effect handlers that reduce it to the base monad (often IO). The ability to modify functionality in a cross-cutting way is concentrated in the effect handler which is at the discretion of the call site, not the implementation site. This is not quite AOP but it's in the same space. It's hard to see in small apps but quickly emerges as the scale of a Haskell application grows.
tathougies 9y ago
How are monad transformers a hack? They have a solid theory behind them. i'm not sure where you got the idea that they 'make monads compose'. Monads don't compose. It's nonsensical to talk about monad composition in general, because there is nothing about the structure of a monad that allows it to compose (quite the opposite, really). Some things which may form some monads do compose with certain other things that form monads, but this is like saying 'Abelian groups' are the 'hack' you need to make groups commutative -- it's a meaningless statement.
- mavelikara 9y ago
  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...)
lmm 9y ago
> AOP is about cross cutting concerns and being able easily insert similar functionalities in unrelated areas of the code. Yes, monad transformers exist to let you do that. They're the thing that makes it possible to insert an effect in a code area that's using other, unrelated effects.
- hota_mazi 9y ago
  Reread carefully my characterization of AOP. Cross cutting concerns allow you to insert a certain line of code in "file 1 at line 223 and file 2 at line 400" because these lines match a certain type safe regexp. Monad transformers accomplish nothing remotely close to that.
  - lmm 9y ago
    Don't be so rude. > Cross cutting concerns allow you to insert a certain line of code in "file 1 at line 223 and file 2 at line 400" because these lines match a certain type safe regexp. What you're describing is the implementation details of how AOP works. Cross-cutting concerns refers to the problem statement: secondary concerns that need to be addressed in the same way in different parts of the codebase with minimal disruption to the primary logical code in those different parts of the codebase.
justinhj 9y ago
Would it be correct to say that certain implementations of Monad make aspect oriented programming possible? One example is the Writer monad which allows recording the state of a sequence of monad operations. Essentially separating the concerns of logging and the actual computation. Perhaps OP means that combining monads (with transformers) enables multiple of these cross cutting concerns to operate together without knowledge of each other

danharaj 9y ago

Monad transformers are distinct from monad composition, it just seems like they're the same because a monad transformer takes the Identity monad to some other monad. The correct conceptualization of monad composition is a distributive law called as such because it generalizes distributive laws from algebra. Of course the two are related. Monad transformers allow one to slice up the functionality and concerns of a program in a dimension different from slicing of a program into components that are then composed together; e.g. a bunch of functions that call each other or a bunch of objects that pass messages between themselves. Each monad transformer in a transformer stack adds functionality and concerns that the other parts of the stack don't need to care about. Components can then be written polymorphically in the concerns they care about allowing them to be instantiated wherever the capabilities they need are present. Ultimately a program is instantiated to a particular transformer stack and then it is supplied effect handlers that reduce it to the base monad (often IO). The ability to modify functionality in a cross-cutting way is concentrated in the effect handler which is at the discretion of the call site, not the implementation site. This is not quite AOP but it's in the same space. It's hard to see in small apps but quickly emerges as the scale of a Haskell application grows.

tathougies 9y ago

How are monad transformers a hack? They have a solid theory behind them. i'm not sure where you got the idea that they 'make monads compose'. Monads don't compose. It's nonsensical to talk about monad composition in general, because there is nothing about the structure of a monad that allows it to compose (quite the opposite, really). Some things which may form some monads do compose with certain other things that form monads, but this is like saying 'Abelian groups' are the 'hack' you need to make groups commutative -- it's a meaningless statement.

mavelikara 9y ago
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...)

lmm 9y ago

> AOP is about cross cutting concerns and being able easily insert similar functionalities in unrelated areas of the code. Yes, monad transformers exist to let you do that. They're the thing that makes it possible to insert an effect in a code area that's using other, unrelated effects.

hota_mazi 9y ago
Reread carefully my characterization of AOP. Cross cutting concerns allow you to insert a certain line of code in "file 1 at line 223 and file 2 at line 400" because these lines match a certain type safe regexp. Monad transformers accomplish nothing remotely close to that.
- lmm 9y ago
  Don't be so rude. > Cross cutting concerns allow you to insert a certain line of code in "file 1 at line 223 and file 2 at line 400" because these lines match a certain type safe regexp. What you're describing is the implementation details of how AOP works. Cross-cutting concerns refers to the problem statement: secondary concerns that need to be addressed in the same way in different parts of the codebase with minimal disruption to the primary logical code in those different parts of the codebase.

justinhj 9y ago

Would it be correct to say that certain implementations of Monad make aspect oriented programming possible? One example is the Writer monad which allows recording the state of a sequence of monad operations. Essentially separating the concerns of logging and the actual computation. Perhaps OP means that combining monads (with transformers) enables multiple of these cross cutting concerns to operate together without knowledge of each other