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]> 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]. > To post to this group, send email to [email protected]. > > > -- > 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]. -- Danny Navarro | http://dannynavarro.net -- 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].
