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 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

That is the suggestion we are putting forth. =) -Edward On Wed, May 7, 2014 at 7:54 AM, Merijn Verstraaten 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 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

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

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 wrote:

...

That is the suggestion we are putting forth. =)

-Edward

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

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Wed, May 7, 2014 at 12:31 PM, Tom Ellis < tom-lists-haskell-cafe-2013@jaguarpaw.co.uk> 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: https://github.com/haskell/cabal/issues/1792 Michael

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)

On Wed, May 7, 2014 at 5:47 AM, Michael Snoyman wrote:

On Wed, May 7, 2014 at 12:40 PM, Herbert Valerio Riedel wrote:

...

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.

The PVP clearly communicates that if a dependency has a major version bump, then you MUST test your package with the new version to guarantee that your release will build. Those people simply shouldn't have released without testing. Also, people not following the PVP are very simply ALWAYS more prone to the kind of breakage we see here.

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?

+1 here. I'm definitely curious about the reasoning.

On 2014-05-07 at 11:47:25 +0200, Henning Thielemann wrote:

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

Btw, as I can't think of an example right now, what would be an example for code that works with transformers-0.4.0.0 but wouldn't compile anymore with transformers-0.4.1.0? Cheers, hvr

On Wed, May 7, 2014 at 1:34 PM, Tom Ellis < tom-lists-haskell-cafe-2013@jaguarpaw.co.uk> wrote:

On Wed, May 07, 2014 at 12:15:58PM +0200, Herbert Valerio Riedel wrote:

...

On 2014-05-07 at 11:47:25 +0200, Henning Thielemann wrote:

...

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

Btw, as I can't think of an example right now, what would be an example for code that works with transformers-0.4.0.0 but wouldn't compile anymore with transformers-0.4.1.0?

Surely just the reverse of the breaking change?

https://github.com/ibotty/streaming-commons/commit/b1137852e4f58520ad65d01b2...

No, that code is compatible with transformers 0.3, 0.4, and 0.4.1. With the syntax: import Data.Functor.Constant (Constant (Constant), getConstant) We're importing the data type Constrant, the data construct Constant for that data type, and the function getConstant. It doesn't matter if getConstant is a normal function or a field accessor, it can still be accessed by that syntax. Michael

On Wed, May 7, 2014 at 2:41 PM, Tom Ellis < tom-lists-haskell-cafe-2013@jaguarpaw.co.uk> wrote:

...

...

...

Btw, as I can't think of an example right now, what would be an example for code that works with transformers-0.4.0.0 but wouldn't compile anymore with transformers-0.4.1.0?

Surely just the reverse of the breaking change?

https://github.com/ibotty/streaming-commons/commit/b1137852e4f58520ad65d01b2...

...

No, that code is compatible with transformers 0.3, 0.4, and 0.4.1. With

On Wed, May 07, 2014 at 02:10:42PM +0300, Michael Snoyman wrote: the

...

syntax:

import Data.Functor.Constant (Constant (Constant), getConstant)

We're importing the data type Constrant, the data construct Constant for that data type, and the function getConstant. It doesn't matter if getConstant is a normal function or a field accessor, it can still be accessed by that syntax.

Then I don't understand why field accessors are even *allowed* to be imported beneath the type. Surely that's only necessary to disambiguate constructors from types?

In the case here, the syntax: import Control.Monad.Trans.Reader (ReaderT (..)) is very convenient. But it's true that you don't really gain much from the distinction between these two: import Control.Monad.Trans.Reader (ReaderT (ReaderT, runReaderT)) import Control.Monad.Trans.Reader (ReaderT (ReaderT), runReaderT) Perhaps the latter should be considered a better approach, since it's more resilient to changes in datatypes. Michael

Am 07.05.2014 13:43, schrieb Michael Snoyman:

In the case here, the syntax:

import Control.Monad.Trans.Reader (ReaderT (..))

is very convenient. But it's true that you don't really gain much from the distinction between these two:

import Control.Monad.Trans.Reader (ReaderT (ReaderT, runReaderT)) import Control.Monad.Trans.Reader (ReaderT (ReaderT), runReaderT)

Perhaps the latter should be considered a better approach, since it's more resilient to changes in datatypes.

However, even if imported in the second way, runReaderT identifier can be used in record field update syntax. I guess it would be more consistent to allow only the use as a function when imported like an ordinary function.

* Herbert Valerio Riedel [2014-05-07 12:15:58+0200]

Btw, as I can't think of an example right now, what would be an example for code that works with transformers-0.4.0.0 but wouldn't compile anymore with transformers-0.4.1.0?

{-# LANGUAGE RecordWildCards #-} import qualified Control.Monad.Trans.Identity as I I.Identity {..} = I.Identity () runIdentity = () (untested, but I think it does the trick) Roman

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 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 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 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

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 mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

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 mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org