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]> 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].
--
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].
