3 ms·

Thanks for the links! I'm really curious about what Haskell can come up with for a front-end story. Do you think that Purescript's row typing (as seen in recor

Thanks for the links! I'm really curious about what Haskell can come up with for a front-end story. Do you think that Purescript's row typing (as seen in records and the Eff monad/effect system) is a viable replacement for monad transformer stacks? I "get" MT stacks but I find them heavyweight when what is most often desired is commutative set building of capabilities rather than MT-style stacking.

purescript 11y ago
Monad transformers and PureScript's row-based effects are two complementary approaches to the problem of extensible effects. Some effects in PureScript look a lot like the effects provided by certain monad transformers (StateT/ST/Ref, ExceptT/Exception, etc.), but there are differences in terms of how things compose. Take StateT and ExceptT for example: you can compose them in two ways, and get two different monad transformer stacks, with different behaviors (surrounding how state propagates when an exception occurs). There are valid use cases for each, but with the ST and Exception effects, there is only one way to combine them: the way the underlying (Javascript) runtimes chooses for us. There are things which each one can do which the other cannot. Fortunately, we can mix and match in PureScript since we have the purescript-transformers library. A typical arrangement is to stick Eff on the bottom of a monad transformer stack. _Edit_: of course, everything you can do with a monad transformer can be done more verbosely with pure functions and the underlying monad, so you _could_ replace monad transformers with Eff in many cases, but in practical terms, it might not be all that useable in some cases.
patrickmn 11y ago
I think you'll find this interesting: https://www.youtube.com/watch?v=4nTnC0t7pzY https://www.youtube.com/watch?v=4nTnC0t7pzY
tel 11y ago
Consider mtl then. It provides commutative capability set building semantics from the user's POV and then only asks the consumer to make final stack-ordering/effect specification decisions.
- dllthomas 11y ago
  I find mtl pretty close to a sweet spot. The one thing I wish for is to be able to constrain effect order as a user (using your terminology above) when I'm writing code where one ordering or another is incorrect. The closest I can come is to fix the top of the stack, which suffices for correctness but puts some unnecessary burden on the consumer.
  - tel 11y ago
    My solution is to make a new typeclass which implies the order you demand. It'll all be social contract driven, but until we have dependent types one cannot ask for more.
    - dllthomas 11y ago
      Ah, good call!

purescript 11y ago

Monad transformers and PureScript's row-based effects are two complementary approaches to the problem of extensible effects. Some effects in PureScript look a lot like the effects provided by certain monad transformers (StateT/ST/Ref, ExceptT/Exception, etc.), but there are differences in terms of how things compose. Take StateT and ExceptT for example: you can compose them in two ways, and get two different monad transformer stacks, with different behaviors (surrounding how state propagates when an exception occurs). There are valid use cases for each, but with the ST and Exception effects, there is only one way to combine them: the way the underlying (Javascript) runtimes chooses for us. There are things which each one can do which the other cannot. Fortunately, we can mix and match in PureScript since we have the purescript-transformers library. A typical arrangement is to stick Eff on the bottom of a monad transformer stack. _Edit_: of course, everything you can do with a monad transformer can be done more verbosely with pure functions and the underlying monad, so you _could_ replace monad transformers with Eff in many cases, but in practical terms, it might not be all that useable in some cases.

patrickmn 11y ago

I think you'll find this interesting: https://www.youtube.com/watch?v=4nTnC0t7pzY https://www.youtube.com/watch?v=4nTnC0t7pzY

tel 11y ago

Consider mtl then. It provides commutative capability set building semantics from the user's POV and then only asks the consumer to make final stack-ordering/effect specification decisions.

dllthomas 11y ago
I find mtl pretty close to a sweet spot. The one thing I wish for is to be able to constrain effect order as a user (using your terminology above) when I'm writing code where one ordering or another is incorrect. The closest I can come is to fix the top of the stack, which suffices for correctness but puts some unnecessary burden on the consumer.
- tel 11y ago
  My solution is to make a new typeclass which implies the order you demand. It'll all be social contract driven, but until we have dependent types one cannot ask for more.
  - dllthomas 11y ago
    Ah, good call!