concrete functor and monad transformers
#24Add DeclareT transformer
swagger2 package has Data.Swagger.Declare 1 module where a DeclareT monad transformer is defined. Since it is a general structure, it might make sense to add it to the transformers package.
At first glance this looked like a special case of StateT, but now I see it's a new species. I guess both lazy and strict versions would be required. The latter might be a replacement for the useless strict WriterT. The name "Declare" doesn't seem general enough, though.
Yes, this is a new species.
I named it "Declare" because I used it to declare definitions, but I agree that name is not general enough. Here are some alternative names: Patch/Patcher, Update/Updater. We can leave "look" method as is and "declare" to "patch" or "update".
I was thinking it's something like an accumulator. On further reflection, I think it will have the same non-constant space behaviour as WriterT, so maybe there's no point to a strict version. It also uses twice as many monoid operations as WriterT or a StateT-based accumulator.
Still, a new species is interesting. To fit with WriterT and StateT, we'd want to swap the order of the pair, and of the arguments to (<>). It would also be useful to have monad transformations from ReaderT (pair the result with mempty) and WriterT (ignore the input), and to StateT (add the input into the output).
Maybe Accum and AccumT then? What about "look" and "declare"? What should we name those?
Indeed this version uses twice as many monoid operations. I should reflect that in the documentation though.
I see that I need to swap pair to preserve consistency with WriterT and StateT. However it seems that I have arguments to mappend correct.
I agree that it can be useful to go from ReaderT/WriterT and to StateT. Thanks for the suggestion!
I have forked this repo and made this new species available as AccumT. Please see
Control.Monad.Trans.Accum. I am new to Darcs (and Darcs Hub) so I am not sure what is the usual workflow here.
I've merged your patches, though we may think of better names later. You're right about the mappend order matching WriterT.
listenis not interesting for
AccumT(since we have
look), we probably need to add an analogue for
pass(under a different name I guess).
Should we ask on the mailing list and/or reddit about better names?
I also think at least one use case should be added to the documentation (like for
ReaderT) might make sense for