I never use the `mtl` in my own code. I stick exclusively to
`transformers`. Pretty much the only useful thing the `mtl` does is
auto-lift `catch`, but that is unsound, so it is not worth it.
On 5/13/14, 7:15 AM, Pierre R wrote:
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
<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]
<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].
