3 ms·

Can you share a bit more? I'm not familiar with Monad transformers.

LukeHoersten 13y ago
Monad transformers are just monads wrapping other monads. I actually like it and think it's a really clean way to organize your state, IO, etc. For example, you could have a Reader wrapping a Writer wrapping a State wrapping IO. The reader is your configs, the writer is for error logging, the state is for some application map, and the IO is for doing networking or something. That's an extreme case but it's nice to lay it out in that way.
- lurker14 13y ago
  That's a special case, because RWS already exists (Reader, Writer, and State all commute), and wraps IO easily. Light overview of the issue: http://ro-che.info/articles/2012-01-02-composing-monads.html http://ro-che.info/articles/2012-01-02-composing-monads.html It's the other cases that get head-desk-banging. This paper is great, but shows what a high mental tax you pay to get highly-principled programs: http://www.grabmueller.de/martin/www/pub/Transformers.en.html http://www.grabmueller.de/martin/www/pub/Transformers.en.htm... At the end of the day, most people on most projects seem to prefer sacrificing some formal specification (and some actual correctness) for getting code running for the common case. Related reddit conversation: http://reddit.com/r/haskell/comments/rd2t5/i_love_rwst_r_w_s_io_a_to_ease_the_transition/ http://reddit.com/r/haskell/comments/rd2t5/i_love_rwst_r_w_s...
- mynameisme 13y ago
  lurker14, you're shadow banned. He/she said: That's a special case, because RWS already exists (Reader, Writer, and State all commute), and wraps IO easily. Light overview of the issue: http://ro-che.info/articles/2012-01-02-composing-monads.html http://ro-che.info/articles/2012-01-02-composing-monads.html It's the other cases that get head-desk-banging. This paper is great, but shows what a high mental tax you pay to get highly-principled programs: http://www.grabmueller.de/martin/www/pub/Transformers.en.htm.. http://www.grabmueller.de/martin/www/pub/Transformers.en.htm.... At the end of the day, most people on most projects seem to prefer sacrificing some formal specification (and some actual correctness) for getting code running for the common case. Related reddit conversation: http://reddit.com/r/haskell/comments/rd2t5/i_love_rwst_r_w_s.. http://reddit.com/r/haskell/comments/rd2t5/i_love_rwst_r_w_s....
- nicolast 13y ago
  That's not an extreme case at all, I'd even argue RWS(T) (or its 'manual' version) is a very common stack. As an example, I use RWST in Kontiki, my implementation of the Raft consensus protocol, where the R part contains configuration (e.g. the set of nodes in the cluster), the W part is filled with 'commands' to be executed after an FSM transition as a reaction on some event (incoming message, timeout,...), where 'commands' are things like 'send this message to node N', 'broadcast this message to all nodes', 'append this entry to the replicated log' or 'log this message (for debugging)', and finally the S part provides access to the current state. Every FSM transition returns the new state, and a list of commands to execute (& the updated state of the S part, but that's discarded). All you need to provide is an 'interpreter' for the commands. This approach makes testing very easy: I can start at any desired state and event (that's just pure data), run the FSM on that (which is also a pure operation, although that's slightly complicated due to the MonadLog implementation which should underlie RWST, but that's besides this discussion), and check whether the output state & commands are the ones I expect, without mocking any networking or intercepting other IO. [update] As an example of what this looks like from inside the FSM code, see https://github.com/NicolasT/kontiki/blob/master/src/Network/Kontiki/Raft/Candidate.hs#L34 https://github.com/NicolasT/kontiki/blob/master/src/Network/... This is a rather straight-forward implementation of the algorithm and looks imperative, but is 100% pure (with all its benefits).

Monad transformers are just monads wrapping other monads. I actually like it and think it's a really clean way to organize your state, IO, etc. For example, you could have a Reader wrapping a Writer wrapping a State wrapping IO. The reader is your configs, the writer is for error logging, the state is for some application map, and the IO is for doing networking or something. That's an extreme case but it's nice to lay it out in that way.

lurker14 13y ago
That's a special case, because RWS already exists (Reader, Writer, and State all commute), and wraps IO easily. Light overview of the issue: http://ro-che.info/articles/2012-01-02-composing-monads.html http://ro-che.info/articles/2012-01-02-composing-monads.html It's the other cases that get head-desk-banging. This paper is great, but shows what a high mental tax you pay to get highly-principled programs: http://www.grabmueller.de/martin/www/pub/Transformers.en.html http://www.grabmueller.de/martin/www/pub/Transformers.en.htm... At the end of the day, most people on most projects seem to prefer sacrificing some formal specification (and some actual correctness) for getting code running for the common case. Related reddit conversation: http://reddit.com/r/haskell/comments/rd2t5/i_love_rwst_r_w_s_io_a_to_ease_the_transition/ http://reddit.com/r/haskell/comments/rd2t5/i_love_rwst_r_w_s...
mynameisme 13y ago
lurker14, you're shadow banned. He/she said: That's a special case, because RWS already exists (Reader, Writer, and State all commute), and wraps IO easily. Light overview of the issue: http://ro-che.info/articles/2012-01-02-composing-monads.html http://ro-che.info/articles/2012-01-02-composing-monads.html It's the other cases that get head-desk-banging. This paper is great, but shows what a high mental tax you pay to get highly-principled programs: http://www.grabmueller.de/martin/www/pub/Transformers.en.htm.. http://www.grabmueller.de/martin/www/pub/Transformers.en.htm.... At the end of the day, most people on most projects seem to prefer sacrificing some formal specification (and some actual correctness) for getting code running for the common case. Related reddit conversation: http://reddit.com/r/haskell/comments/rd2t5/i_love_rwst_r_w_s.. http://reddit.com/r/haskell/comments/rd2t5/i_love_rwst_r_w_s....
nicolast 13y ago
That's not an extreme case at all, I'd even argue RWS(T) (or its 'manual' version) is a very common stack. As an example, I use RWST in Kontiki, my implementation of the Raft consensus protocol, where the R part contains configuration (e.g. the set of nodes in the cluster), the W part is filled with 'commands' to be executed after an FSM transition as a reaction on some event (incoming message, timeout,...), where 'commands' are things like 'send this message to node N', 'broadcast this message to all nodes', 'append this entry to the replicated log' or 'log this message (for debugging)', and finally the S part provides access to the current state. Every FSM transition returns the new state, and a list of commands to execute (& the updated state of the S part, but that's discarded). All you need to provide is an 'interpreter' for the commands. This approach makes testing very easy: I can start at any desired state and event (that's just pure data), run the FSM on that (which is also a pure operation, although that's slightly complicated due to the MonadLog implementation which should underlie RWST, but that's besides this discussion), and check whether the output state & commands are the ones I expect, without mocking any networking or intercepting other IO. [update] As an example of what this looks like from inside the FSM code, see https://github.com/NicolasT/kontiki/blob/master/src/Network/Kontiki/Raft/Candidate.hs#L34 https://github.com/NicolasT/kontiki/blob/master/src/Network/... This is a rather straight-forward implementation of the algorithm and looks imperative, but is 100% pure (with all its benefits).