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
<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]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[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].
