Proposal: merge either into transformers

[Ross Paterson]

On Sun, Apr 27, 2014 at 10:47:56AM +0300, Michael Snoyman wrote:
> On Sat, Apr 26, 2014 at 9:57 PM, Ross Paterson <R.Paterson at city.ac.uk> wrote:
> > would be incompatible with the lazy WriterT in subtle ways
> 
> That would be troubling, but I'm not sure in which ways it's incompatible. Do
> you have any examples?

The Applicative and Alternative instances would have different contexts, and
there would be no instances for Foldable, Traversable, Eq, Ord, Read or Show.

> The advantage of having WriterT implemented in terms of strict StateT
> is that many people will automatically get the fix when upgrading
> to transformers 0.4.  Also, the writer API itself is very convenient
> for many common use cases, so it would be nice if there was a version
> available that didn't leak memory.

Invisibly increasing strictness cuts both ways: some people get space
savings, while others get non-termination.  (Although one might say
they're not using it properly, that seems a harsh punishment.)  But I'm
more concerned about the complication.  Currently the transformers are
transparent, and people can think about the type structure of the monad
they're building.  This very transformer is already there; it seems
simpler to direct people to it instead of having another copy.  The API
point is an issue, though.