Proposal: merge either into transformers

[Michael Snoyman]

On Sat, Apr 26, 2014 at 11:28 AM, Ross Paterson <R.Paterson at city.ac.uk>wrote:

> On Sat, Apr 26, 2014 at 09:16:57AM +0300, Roman Cheplyaka wrote:
> > * Ross Paterson <R.Paterson at city.ac.uk> [2014-04-26 01:21:09+0100]
> > > Instead of EitherT, the next version will deprecate ErrorT in favour
> > > of a transformer ExceptT with base monad Except.  The idea is to have
> > > analogous transformers and monads
> > >
> > >     ExceptT : Except : Either
> > >     WriterT : Writer : (,)
> > >     ReaderT : Reader : (->)
> >
> > Great! When do you plan to make a release?
>
> Let's say Wednesday, if no-one notices a major problem.
>
> > > Pre-release docs are here:
> > >
> > >
> http://code.haskell.org/~ross/transformers/dist/doc/html/transformers/
> >
> > The docs for Control.Monad.Trans.Writer.Strict say:
> >
> >   >  Although the output is built strictly, it is not possible to
> achieve linear
> >   >  space behaviour with this transformer: for that, use
> >   >  Control.Monad.Trans.State.Strict instead.
> >
> > I think it should be "constant", not "linear".
>
> Indeed -- thanks for catching that.  I wonder whether the strict writer
> is of any use at all.
>
>
I think it's worth resurrecting Gabriel's proposed modification to have the
strict writer transformer exposed as an abstract type, built on top of
StateT (or using the same implementation as StateT). I've been bitten by
the laziness of strict Writer in the past, and thanks to Gabriel's email, I
knew how to solve the problem. But I think many people will be misled by
the name, documentation improvements notwithstanding.

*If* it's exposed as an abstract type, I'd also like to propose that a
.Internal module be available for exposing the constructor, as some
libraries will have legitimate need of looking at the constructor.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140426/455fc749/attachment.html>