transformers 0.4: change in accessor function exports?

[Carter Schonwald]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140506/0a4d571d/attachment.html>