On 2008 Sep 30, at 17:59, Derek Elkins wrote:

On Tue, 2008-09-30 at 13:20 -0700, Don Stewart wrote:

...

noteed:

...

I'd like to know, now that time got by a bit, what the writers of the X monad think about the use of the ReaderT/WriterT/IO brought to them (to isolate Configuration data and dynamic data and glue them together with IO). Are you happy of it, did it make things easier or not, would you do it again ?

It made the structuring and invariants between runtime data, and configuration data clean and precise. Yes, A+++ would buy again.

xmonad is a little too alive to be doing postmortems yet

I was wondering what he knew that the rest of us didn't.... -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

2008/10/1 Jason Dagit :

On Tue, Sep 30, 2008 at 1:20 PM, Don Stewart wrote:

...

noteed:

...

Hi,

I'd like to know, now that time got by a bit, what the writers of the X monad think about the use of the ReaderT/WriterT/IO brought to them (to isolate Configuration data and dynamic data and glue them together with IO). Are you happy of it, did it make things easier or not, would you do it again ?

It made the structuring and invariants between runtime data, and configuration data clean and precise. Yes, A+++ would buy again.

I can add to this, saying that I used WriterT/ReaderT and Unique in a CodeGen monad I created for a compiler I'm writing and this approach of stacking monads (well, really transformers) works amazingly well. Many of the existing monads abstractly handle a particular task very well. When you combine this with generalized newtype deriving it's not just code reuse, it's also code specialization. You quickly glue together existing functionality that works but expose it with the API that meets your problem domain. I'd say this is not unlike the way people glue together unix tools on the command line. This is RAD in Haskell.

I agree with Don, I would buy this again. In fact, I've already placed an order for use in future projects.

Thanks for your answer (to Don too). While building the stack (of transformers), do you implement several things with each one its transformer (or directly its corresponding monad) or do you try to make the good combination first ? If the former (combine them later), is it a problem to add lift (or liftIO) to go deep enough in the stack ? What approach do you use ? Thanks, Thu