Re: Proposal to solve the `EitherT` problem.

13 Aug 2013

      For me, the name EitherT wins by a large margin.  Way back when I
first learned about MaybeT, it totally rocked my world.  I had been
plagued for quite some time by the problems that MaybeT addresses but
didn't know of the solution.  I had already seen things like ReaderT
and StateT, but for some reason I hadn't yet made the connection to
how the idea would carry over to the Maybe monad.  After I learned
about MaybeT, EitherT was the natural name I expected.  If EitherT had
been in transformers, I think I would have used it even sooner.

I think the discoverability of the name EitherT is huge win given the
existing conventions.  I think I had even seen ErrorT before MaybeT,
but the name obscured its significance for me.

Also, as Ed pointed out, I do use the errors package in snap.  These
days I use errors in pretty much every substantial project I work on.
Usually that includes EitherT, so renaming it would impose a huge
cost.

On Tue, Aug 13, 2013 at 4:43 PM, Dag Odenhall  wrote:
...
Also, grepping hackage is all well and good but that‘s ignoring all the code
that’s either not released yet or is closed source. That's probably the case
with a lot of application code, with hackage having mostly libraries. Just a
thought.
On Tue, Aug 13, 2013 at 10:39 PM, Edward Kmett  wrote:
...
Did you consider the transitive dependency from errors?
Errors re-exports Control.Monad.Trans.Either from Control.Error.
In particular I noted that snap then depends on errors.
I didn't grep through the source though.
-Edward
On Tue, Aug 13, 2013 at 1:25 PM, Ross Paterson 
wrote:
...
On Tue, Aug 13, 2013 at 10:30:23AM -0400, Edward Kmett wrote:
...
An argument against just randomly bikeshedding the name it is there
are a lot of packages out there currently transitively depending on
the existing either package, due to the popularity of Tekmo's errors
package and the fact that it has been picked up by snap. So half of
the web-apps in the ecosystem depend on this type transitively.
Fortunately it seems that EitherT is only used by the following packages:
citation-resolve coroutine-object CSPM-Frontend errors
        happstack-heist hoodle-core hoodle-parser katt pdf-toolbox-core
        pianola restricted-workers terminfo-hs
Moreover adding a new module and type means people can switch over an
extended timescale.  Thus I think internal consistency within
transformers
outweighs compatibility with the existing EitherT in this case.
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries

Re: Proposal to solve the `EitherT` problem.

MightyByte