FWIW, I had been surprised recently that as soon as you start using Control-Monad-Trans from mtl you need to add transformer into your cabal file. My initial thought was that `mtl` would use transformer behind my back (and eventually ditch it if it makes some sense). I guess I am being quite naive here. So I don't really see how `mtl` can be the default choice (I remind ekmett saying something along this line) if you need `transformers` to do a simple lifting.
On Monday, May 12, 2014 10:53:23 PM UTC+2, Gabriel Gonzalez wrote: > > I was disappointed, too: > > * It introduced *unnecessary* breaking changes. If Ross hadn't moved > the run functions out of the data type definitions this would have been > a `0.3.1.0` release and nobody would have had to upgrade. > > * Ross didn't consult with anybody on this and repeatedly ignored the > consensus recommendations on the libraries mailing list > > * Ross didn't fix any of the real problems (space leaks in WriterT being > the biggest one) > > It also makes my life much harder as maintainer of the `errors` > package. I have to decide whether to support the (terribly-named) > `ExceptT` type or `EitherT`. I'm probably going to stick to `EitherT`. > > On 5/12/14, 12:40 PM, Danny Navarro wrote: > > To be honest I was a bit disappointed with this release because most > > `transformers` dependent packages have to bother bumping the new > > version but still not much is gained with this update. It's also odd > > that with the release of GHC 7.8.2 came with `transfomers-0.3` and > > weeks later `transformers-0.4` was released. The migration from 7.6.3 > > to 7.8.3 was a good opportunity to push more aggressive changes. I > > guess I'll keep using `either` package as if no real upgrade to > > `transformers` came about. > > > > Or maybe this is a change in the release cycle of `transformers`, do > > you know if new releases of transformers are expected soon? > > > > On Mon, May 12, 2014 at 6:39 PM, Gabriel Gonzalez > > <[email protected]<javascript:>> > wrote: > >> The main changes that I'm aware of are: > >> > >> * ExceptT is added (it's basically `ErrorT` without the `Error` type > class > >> constraint) > >> > >> * Run functions have been moved outside of the constructors, presumably > to > >> eventually pave the way for making the constructors opaque data types. > That > >> means that you can no longer do this: > >> > >> import Control.Monad.Trans.Maybe (Maybe(runMaybeT)) -- Error for > >> transformers-0.4.0.0 > >> > >> Now you have to do this: > >> > >> import Control.Monad.Trans.Maybe (Maybe, runMaybeT) -- correct > >> > >> * There's a new `Control.Monad.Signatures` module with some useful type > >> synonyms > >> > >> === > >> > >> Here are things that were *not* changed: > >> > >> * No changes to the `transformers` `ListT` > >> > >> * No changes to `WriterT` (i.e. it still leaks space) > >> > >> > >> On 5/12/14, 9:23 AM, Pierre R wrote: > >> > >> May I hijack this thread to ask about the changes in transformers 0.4 ? > >> > >> I mean the specific about ErrorT, ListT that have been discussed > before. > >> > >> Cheers > >> On Monday, May 12, 2014 4:13:11 PM UTC+2, Gabriel Gonzalez wrote: > >>> There are two issues with using `cabal freeze`: > >>> > >>> 1) It only works if `cabal` succeeds once, but the chance of it > >>> succeeding goes down greatly if you remove upper bounds > >>> 2) Once you remove upper bounds from a package it makes `cabal` much > >>> more likely to fail on a permanent basis. Adding just one package in > >>> the history that has no upper bound means that cabal will always > >>> consider that package when it is trying to work around that upper > bound, > >>> even if it's a really old package. > >>> > >>> Also, if I remember correctly they are adding (or maybe already added) > a > >>> flag to have `cabal` ignore upper bounds, which I think is the best > >>> solution. > >>> > >>> On 05/12/2014 04:46 AM, Danny Navarro wrote: > >>>> My intention is not to start a discussion about whether upper limit > >>>> bounds is better than not having them (I prefer to not have them > >>>> though), but after the hairy process of updating some `pipes` > packages > >>>> to `transfomers-0.4`, I was wondering if the new `cabal freeze`[1] > >>>> feature would cover the use cases for which upper limits are > currently > >>>> used. > >>>> > >>>> With cabal freeze we could pin the versions for which we are sure it > >>>> builds, while allowing easier upgrades for packages which use the > >>>> dependency. This doesn't guarantee that there won't be breakages, but > >>>> at least, IMHO, the dependencies of packages with many `pipes` > >>>> dependencies will be easier to update. Notice that in practice upper > >>>> limits doesn't guarantee flawless builds either. > >>>> > >>>> [1]: http://blog.johantibell.com/2014/04/announcing-cabal-120.html > >>>> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Haskell Pipes" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to [email protected] <javascript:>. > >> To post to this group, send email to > >> [email protected]<javascript:>. > > >> > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Haskell Pipes" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to [email protected] <javascript:>. > >> To post to this group, send email to > >> [email protected]<javascript:>. > > > > > > > -- You received this message because you are subscribed to the Google Groups "Haskell Pipes" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected].
