transformers 0.4: change in accessor function exports?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

transformers 0.4: change in accessor function exports?

Michael Snoyman
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.

Michael


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: transformers 0.4: change in accessor function exports?

Ross Paterson-2
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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: transformers 0.4: change in accessor function exports?

Edward Kmett-2
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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: transformers 0.4: change in accessor function exports?

Merijn Verstraaten
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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: transformers 0.4: change in accessor function exports?

Carter Schonwald
agree with  merjin and edward... 


On Tue, May 6, 2014 at 5:54 PM, Merijn Verstraaten <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: transformers 0.4: change in accessor function exports?

Edward Kmett-2
In reply to this post by Merijn Verstraaten
That is the suggestion we are putting forth. =)

-Edward


On Wed, May 7, 2014 at 7:54 AM, Merijn Verstraaten <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> wrote:
That is the suggestion we are putting forth. =)

-Edward


On Wed, May 7, 2014 at 7:54 AM, Merijn Verstraaten <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: transformers 0.4: change in accessor function exports?

Edward Kmett-2
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 <[hidden email]> 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 <[hidden email]> wrote:
That is the suggestion we are putting forth. =)

-Edward


On Wed, May 7, 2014 at 7:54 AM, Merijn Verstraaten <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries




_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: transformers 0.4: change in accessor function exports?

Ross Paterson-2
In reply to this post by Edward Kmett-2
On Wed, May 07, 2014 at 07:30:03AM +1000, 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.

My concern is not the implementation, it's the interface.

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

I'm convinced that this change is the right thing to do, but I haven't
managed it at all well.  So I'll do a minor release re-instating the
fields in short order, but still intend to remove them in the next major
release (with more preparation).
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: transformers 0.4: change in accessor function exports?

John Lato-2
In reply to this post by Edward Kmett-2
I don't really care one way or the other how this is resolved, but does it strike anyone else that current practices must be remarkably fragile for such a minor change (which doesn't even change exported names!) to supposedly cause so much breakage?

John L.


On Tue, May 6, 2014 at 2:30 PM, Edward Kmett <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: transformers 0.4: change in accessor function exports?

Felipe Lessa
In reply to this post by Ross Paterson-2
Em 06-05-2014 19:57, Ross Paterson escreveu:

> On Wed, May 07, 2014 at 07:30:03AM +1000, 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.
>
> My concern is not the implementation, it's the interface.
>
>> 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.
>
> I'm convinced that this change is the right thing to do, but I haven't
> managed it at all well.  So I'll do a minor release re-instating the
> fields in short order, but still intend to remove them in the next major
> release (with more preparation).
I'm sorry, but why are you convinced of this?

Cheers,

--
Felipe.


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

signature.asc (919 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: transformers 0.4: change in accessor function exports?

Henning Thielemann-4
In reply to this post by John Lato-2
Am 07.05.2014 01:03, schrieb John Lato:

> I don't really care one way or the other how this is resolved, but does
> it strike anyone else that current practices must be remarkably fragile
> for such a minor change (which doesn't even change exported names!) to
> supposedly cause so much breakage?

With qualified imports there would be no breakage ...

However, names in mtl and thus transformers were not designed for
qualified import. :-(

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: transformers 0.4: change in accessor function exports?

Joachim Breitner-2
Hi,

Am Mittwoch, den 07.05.2014, 08:33 +0200 schrieb Henning Thielemann:

> Am 07.05.2014 01:03, schrieb John Lato:
> > I don't really care one way or the other how this is resolved, but does
> > it strike anyone else that current practices must be remarkably fragile
> > for such a minor change (which doesn't even change exported names!) to
> > supposedly cause so much breakage?
>
> With qualified imports there would be no breakage ...
>
> However, names in mtl and thus transformers were not designed for
> qualified import. :-(
would it?

/tmp $ echo 'module Foo where newtype Foo = Foo {unFoo :: ()}' > Foo.hs
/tmp $ echo 'module Bar where import qualified Foo (Foo(..)) ; bar = Foo.unFoo' > Bar.hs
/tmp $ ghc -c Foo.hs; ghc -c Bar.hs
/tmp $ echo 'module Foo where newtype Foo = Foo (); unFoo (Foo x) = x ' > Foo.hs
/tmp $ ghc -c Foo.hs; ghc -c Bar.hs

Bar.hs:1:57: Not in scope: `Foo.unFoo'

Greetings,
Joachim

--
Joachim “nomeata” Breitner
  [hidden email]http://www.joachim-breitner.de/
  Jabber: [hidden email]  • GPG-Key: 0xF0FBF51F
  Debian Developer: [hidden email]


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: transformers 0.4: change in accessor function exports?

Henning Thielemann-4
Am 07.05.2014 10:49, schrieb Joachim Breitner:

> Hi,
>
> Am Mittwoch, den 07.05.2014, 08:33 +0200 schrieb Henning Thielemann:
>> Am 07.05.2014 01:03, schrieb John Lato:
>>> I don't really care one way or the other how this is resolved, but does
>>> it strike anyone else that current practices must be remarkably fragile
>>> for such a minor change (which doesn't even change exported names!) to
>>> supposedly cause so much breakage?
>>
>> With qualified imports there would be no breakage ...
>>
>> However, names in mtl and thus transformers were not designed for
>> qualified import. :-(
>
> would it?
>
> /tmp $ echo 'module Foo where newtype Foo = Foo {unFoo :: ()}' > Foo.hs
> /tmp $ echo 'module Bar where import qualified Foo (Foo(..)) ; bar = Foo.unFoo' > Bar.hs

With qualified import I mean

import qualified Foo as Foo


Importing qualified with explicit import list is somehow done twice,
because Foo.unFoo cannot clash with other identifiers, unless you use
the abbreviation Foo twice.

> /tmp $ ghc -c Foo.hs; ghc -c Bar.hs
> /tmp $ echo 'module Foo where newtype Foo = Foo (); unFoo (Foo x) = x ' > Foo.hs
> /tmp $ ghc -c Foo.hs; ghc -c Bar.hs
>
> Bar.hs:1:57: Not in scope: `Foo.unFoo'

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: transformers 0.4: change in accessor function exports?

Joachim Breitner-2
Hi,

Am Mittwoch, den 07.05.2014, 11:11 +0200 schrieb Henning Thielemann:
> With qualified import I mean
>
> import qualified Foo as Foo
>
>
> Importing qualified with explicit import list is somehow done twice,
> because Foo.unFoo cannot clash with other identifiers, unless you use
> the abbreviation Foo twice.

quite right; sorry.

Greetings,
Joachim

--
Joachim “nomeata” Breitner
  [hidden email]http://www.joachim-breitner.de/
  Jabber: [hidden email]  • GPG-Key: 0xF0FBF51F
  Debian Developer: [hidden email]


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: transformers 0.4: change in accessor function exports?

Tom Ellis
In reply to this post by Edward Kmett-2
On Wed, May 07, 2014 at 08:34:38AM +1000, Edward Kmett wrote:
> You don't deprecate versions in hackage, you deprecate whole packages.

Not sure if I missed the point, but you can deprecate versions:

    http://hackage.haskell.org/packages/preferred
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: transformers 0.4: change in accessor function exports?

Michael Snoyman



On Wed, May 7, 2014 at 12:31 PM, Tom Ellis <[hidden email]> wrote:
On Wed, May 07, 2014 at 08:34:38AM +1000, Edward Kmett wrote:
> You don't deprecate versions in hackage, you deprecate whole packages.

Not sure if I missed the point, but you can deprecate versions:

    http://hackage.haskell.org/packages/preferred


You can, and it's a good practice, but unfortunately it won't really change cabal's build plan generation:


Michael 

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: transformers 0.4: change in accessor function exports?

Herbert Valerio Riedel
In reply to this post by Carter Schonwald
On 2014-05-07 at 00:32:33 +0200, Carter Schonwald wrote:
> should the 0.4 release be temporarily marked deprecated so that breakages
> stop for a wee bit?

I know, some of you may not want to hear this, but this will only bite
packages not following the PVP (i.e. those that didn't have upper
bounds)... transformers-0.4 was a major version bump after all, so it
*is* allowed to break the API (whether that was a good design decision
is a different discussion though)
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: transformers 0.4: change in accessor function exports?

Michael Snoyman



On Wed, May 7, 2014 at 12:40 PM, Herbert Valerio Riedel <[hidden email]> wrote:
On 2014-05-07 at 00:32:33 +0200, Carter Schonwald wrote:
> should the 0.4 release be temporarily marked deprecated so that breakages
> stop for a wee bit?

I know, some of you may not want to hear this, but this will only bite
packages not following the PVP (i.e. those that didn't have upper
bounds)... transformers-0.4 was a major version bump after all, so it
*is* allowed to break the API (whether that was a good design decision
is a different discussion though)


Actually, in this case, I've seen some packages that *were* following the PVP get broken by this change, since authors didn't realize this would be a breaking change before releasing a new version of their package with a relaxed upper bound. You can argue about good practices in release procedures, but I just want to make it clear that, in this case, an immediate release of transformers 0.4.1 was incredibly helpful with stropping wider-spread breakage.

I'd still like to come back to the question Felipe asked: why is the change from field labels to explicit functions considered an improvement?

Michael 

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: transformers 0.4: change in accessor function exports?

Henning Thielemann-4
In reply to this post by Herbert Valerio Riedel
Am 07.05.2014 11:40, schrieb Herbert Valerio Riedel:
> On 2014-05-07 at 00:32:33 +0200, Carter Schonwald wrote:
>> should the 0.4 release be temporarily marked deprecated so that breakages
>> stop for a wee bit?
>
> I know, some of you may not want to hear this, but this will only bite
> packages not following the PVP (i.e. those that didn't have upper
> bounds)... transformers-0.4 was a major version bump after all, so it
> *is* allowed to break the API (whether that was a good design decision
> is a different discussion though)

However, turning the runIdentity function back into a record field name
in 0.4.1.0, was another breaking change that only got a minor version
bump. :-(

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
12