ListT proposal for `transformers`

Edward Kmett ekmett at
Sun Jul 14 14:46:19 CEST 2013

The problem with the existing ListT is it is often not a Monad.

Consider IO [Int]

To work with an infinite list you need to distribute an infinite number of
effects into the IO.

I personally would be slightly in favor adding "ListT done right" as a
separate monad, given that the existing one is still rather useful when you
want to use a small number of elements and aren't worried about
non-termination in the base monad, and in those limited circumstances it is
a heck of a lot easier to understand.

A longer summary of the issues with the existing ListT and the original
"ListT done right" proposal has been on the wiki for a long time:

The main arguments against moving it into transformers / mtl. It _has_ been
around for a long time: it is annoyingly complicated to use and has been
packaged up several times in the meantime, and there are multiple similar
alternatives for specific domains that fill in for the weaknesses of even
this approach:

e.g. LogicT, Soutei's FStream, and to a lesser extent things like Luke
Palmer's Omega.

But for all that it is a more 'correct' ListT, hence my being weakly in
favor of finally putting it in a standard location.


On Sun, Jul 14, 2013 at 2:59 AM, Edward Z. Yang <ezyang at> wrote:

> ListT is a kind of delicate monad, because it has interesting
> control flow (arguably one is supposed to use LogicT for anything
> serious, since ).  What makes this particular implementation "ListT
> done right?"
> Edward
> Excerpts from Gabriel Gonzalez's message of Sat Jul 13 20:47:02 -0700 2013:
> > I've been working on a "ListT done right" for submission into
> > `transformers`.  I could split it off into its own package, but I would
> > like to first run it by you all, particularly Ross, to see if this can
> > be included this in `transformers` because I feel that `transformers` is
> > where this belongs.
> >
> > I've lpasted the implementation here:
> >
> >
> >
> > I've written it to follow the spirit of the `transformers` library as
> > closely as possible, both in API, documentation, and source code style.
> >
> > I'm fine with either replacing the old `ListT` implementation or
> > providing both.  I'll leave it to you guys to make the call on that.  As
> > long as the correct version is in `transformers` somewhere then I'm
> > happy.  If I *had* to pick a side, I suppose I would favor replacing the
> > old one.
> >
> > Also, any suggestions for changes are welcome, particularly if they
> > improve the likelihood of this getting into `transformers`.
> >
> _______________________________________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list