transformers 0.4: change in accessor function exports?
Erik Hesselink
hesselink at gmail.com
Wed May 7 11:38:31 UTC 2014
Actually you do. On the new hackage, you can deprecate single
versions, though these are not hard constraints to cabal IIRC, so
their use is limited. For transformers, this could be done at [0].
This would probably be a good idea, if only to show people which
version they should support. I'm guessing it's 0.3.* or 0.4.1, since
that last one was done without a major version bump, implying that the
changes in 0.4.0 'never happened'?
Erik
[0] http://hackage.haskell.org/package/transformers/preferred/edit
On Wed, May 7, 2014 at 12:34 AM, Edward Kmett <ekmett at gmail.com> wrote:
> Carter,
>
> You don't deprecate versions in hackage, you deprecate whole packages.
>
> Slow down and let's let the man reply. ;)
>
> -Edward
>
>
> On Wed, May 7, 2014 at 8:32 AM, Carter Schonwald
> <carter.schonwald at gmail.com> wrote:
>>
>> should the 0.4 release be temporarily marked deprecated so that breakages
>> stop for a wee bit?
>>
>>
>> On Tue, May 6, 2014 at 6:30 PM, Edward Kmett <ekmett at gmail.com> wrote:
>>>
>>> That is the suggestion we are putting forth. =)
>>>
>>> -Edward
>>>
>>>
>>> On Wed, May 7, 2014 at 7:54 AM, Merijn Verstraaten
>>> <merijn at inconsistent.nl> wrote:
>>>>
>>>> Wouldn't it be simpler/less breaking to keep "newtype Identity a =
>>>> Identity { runIdentity :: a }" and simply hand write Show/Read instances
>>>> that function asif it was "newtype Identity a = Identity a", giving us best
>>>> of both worlds?
>>>>
>>>> Cheers,
>>>> Merijn
>>>>
>>>>
>>>> On May 6, 2014, at 23:30 , Edward Kmett wrote:
>>>>
>>>> It may make the code in transformers a bit more confusing for a handful
>>>> of instances, but this is breaking almost every user I've talked to.
>>>>
>>>> This is proving to be a major breaking change as users commonly import
>>>> StateT(..) and go off and use runStateT, etc.
>>>>
>>>> I wrote the imports in mtl 2.2 in such a way that if you recanted and
>>>> chose to switch back to the old style, it'd still work.
>>>>
>>>> I just know that I personally have 200+ modules to change as a result,
>>>> for no better experience as a user.
>>>>
>>>> -Edward
>>>>
>>>>
>>>> On Wed, May 7, 2014 at 3:18 AM, Ross Paterson <R.Paterson at city.ac.uk>
>>>> wrote:
>>>>>
>>>>> On Tue, May 06, 2014 at 07:16:40PM +0300, Michael Snoyman wrote:
>>>>> > One of the changes[1] in transformers 0.4 is as follows:
>>>>> >
>>>>> > 0.3:
>>>>> >
>>>>> > newtype Identity a = Identity { runIdentity :: a }
>>>>> >
>>>>> > 0.4:
>>>>> >
>>>>> > newtype Identity a = Identity a
>>>>> > runIdentity (Identity x) = x
>>>>> >
>>>>> > While this may seem benign, I've already seen three cases where this
>>>>> > caused
>>>>> > breakage[2][3][4].
>>>>> >
>>>>> > Is there a reason for this change in 0.4? If not, I'd like to request
>>>>> > moving
>>>>> > back to the previous formulation to avoid unnecessary breakage.
>>>>>
>>>>> Read and Show instances were introduced in 0.4. With the record form,
>>>>> the default instances for those classes would be very cumbersome.
>>>>> The alternative of defining custom instances that differ from the
>>>>> default
>>>>> ones would make the interface more confusing.
>>>>> _______________________________________________
>>>>> Libraries mailing list
>>>>> Libraries at haskell.org
>>>>> http://www.haskell.org/mailman/listinfo/libraries
>>>>
>>>>
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/libraries
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/libraries
>>>>
>>>
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries
>>>
>>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
More information about the Libraries
mailing list