Thomas,

In my case I omitted BangPatterns from the pragma by accident and was thankful for the update.

Your requirement would be satisfied by just displaying warnings, I guess. --Kazu

On 20 January 2011 02:47, John Meacham wrote:

Allowing this was a specific feature that was included in ghc on purpose (as well as the relaxed if/then layout rule in do statements) So this is definitely a regression.

Ian split this out in this patch: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitdiff;h=201... (You can see the tests here: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=testsuite;a=darcs_commitdiff...) However, when he split it out he made sure that it was still turned on by default unless the package explicitly requested Haskell 98 or 2010 compatibility (with -XHaskell98 or -XHaskell2010) - so I'm not sure why it should cause breakage. I don't have a HEAD build around so I can't find out for myself at the moment. Cheers, Max

Hello,

Yes, it's still on in GHC by default, but Cabal specifies Haskell98 if a language isn't given in the .cabal file.

network probably wants to give NondecreasingIndentation as an extension if impl(ghc >= 7.1).

I'm not asking how to fix packages. Actually the layout of the network package on github has been fixed today. I'm asking why GHC breaks backward compatibility (e.g. FlexibleInstances and BangPatterns) and why maintainers of packages should do boring fixes. What are benefits of such overhead? --Kazu

On 20/01/2011 14:25, Kazu Yamamoto (山本和彦) wrote:

Hello,

...

Yes, it's still on in GHC by default, but Cabal specifies Haskell98 if a language isn't given in the .cabal file.

network probably wants to give NondecreasingIndentation as an extension if impl(ghc>= 7.1).

I'm not asking how to fix packages. Actually the layout of the network package on github has been fixed today.

I'm asking why GHC breaks backward compatibility (e.g. FlexibleInstances and BangPatterns) and why maintainers of packages should do boring fixes. What are benefits of such overhead?

The FlexibleInstances issue is this: http://hackage.haskell.org/trac/ghc/ticket/4841 this was a bug (GHC accepted programs when it shouldn't), and we fixed it. Unfortunately that causes some programs not to compile that did before. The BangPatterns change is this: http://hackage.haskell.org/trac/ghc/ticket/4477 again, it was wrong before (GHC accepted programs when it shouldn't). The layout fix is this change: http://hackage.haskell.org/trac/ghc/changeset/9a82b1ffa35fa4c3927c66a1037a37... Another case where GHC was not strictly standards-compliant, and it was fixed by adding a flag for the extension. These were all bugs, but fixing them broke some code, unfortunately. In cases like this we *could* deprecate the behaviour for one major release with a warning, before removing it. However there's a non-trivial cost to doing so, and in some of these cases it would have been quite awkward to implement the warning (plus the cost of adding tests to make sure we actually got the warning right; it's easy to introduce yet more bugs). Furthermore, deprecations are often ignored, so sometimes the breakage is just delayed. Hopefully that explains why sometimes we make breaking changes. If the breaking change has a high enough impact, then it becomes worthwhile to add backwards compatibility (via warnings / deprecation or whatever). Of course from the point of view of the user, the impact is always either high (it broke) or zero (it didn't) :-) We have to make a judgement as to whether we should spend effort on backwards compatibility or not. Perhaps we're getting it wrong - so feedback from users is always valuable. Cheers, Simon

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/20/11 12:09 , Sittampalam, Ganesh wrote:

Simon Marlow wrote:

...

judgement as to whether we should spend effort on backwards compatibility or not. Perhaps we're getting it wrong - so feedback from users is always valuable.

From the point of view of darcs, which is usually trying to support 2 or 3 GHC versions at a time, one cycle of deprecation makes life a lot simpler. We do look at warnings and try to fix them, but it's nicer not to have to do so in a real hurry.

And of the Haskell Platform, etc. Think of it as the price of failing to avoid success. - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk04bpsACgkQIn7hlCsL25Wh2QCgydcO3kZGxRTePJvp+HvnZloI r/wAn0YIv8ZqN6ZS9WNMvaH86F3AHZgl =m18O -----END PGP SIGNATURE-----

Hi Simon, On Jan 20, 2011, at 17:54, Simon Marlow wrote:

The layout fix is this change:

http://hackage.haskell.org/trac/ghc/changeset/9a82b1ffa35fa4c3927c66a1037a37...

Another case where GHC was not strictly standards-compliant, and it was fixed by adding a flag for the extension.

These were all bugs, but fixing them broke some code, unfortunately. In cases like this we *could* deprecate the behaviour for one major release with a warning, before removing it. However there's a non-trivial cost to doing so, and in some of these cases it would have been quite awkward to implement the warning (plus the cost of adding tests to make sure we actually got the warning right; it's easy to introduce yet more bugs). Furthermore, deprecations are often ignored, so sometimes the breakage is just delayed.

Hopefully that explains why sometimes we make breaking changes. If the breaking change has a high enough impact, then it becomes worthwhile to add backwards compatibility (via warnings / deprecation or whatever). Of course from the point of view of the user, the impact is always either high (it broke) or zero (it didn't) :-) We have to make a judgement as to whether we should spend effort on backwards compatibility or not. Perhaps we're getting it wrong - so feedback from users is always valuable.

I appreciate that you want to make ghc compliant to the standard. But to be honest, it is still the case that ghc defines the de-facto standard of what a Haskell program can be, since many programs do employ one or more ghc-only extensions. In the case of the layout "bug", I think it might be worth considering going the other way: adjusting the standard with what ghc has always done. If I understand correctly, all my code using: foo = do some computation trace "I am here" $ do some more computation will break. I use this style of coding a lot to avoid too much indentation and thus I would have to enable this extension everywhere (and get warnings (or errors?) for older ghcs). Even if we had 2 or 3 implementations of Haskell 2010 in a decade, then they might not have this extension. Furthermore, if they claim they actually do implement the layout extension then they still might get it wrong in some subtle way. An extension is never as well exercised as the non-extension part of the compiler. I therefore think that keeping the number of extensions to a minimum should be a high priority. It seems that the ghc team is going overboard with the amount of extensions and their granularity that I do not believe that there will ever be another compiler since implementing all these extensions is a nightmare. The road of may extensions is leading down the road that the Haskell standards aimed to avoid: having a single implementation defining what a Haskell program can be. So, again, for this particular "extension" I suggest that the layout rule in the standard(s) should be revised -- if I'm mistaken, this will not break other programs. Cheers, Axel

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/20/11 21:12 , Ian Lynagh wrote:

On Thu, Jan 20, 2011 at 09:22:37PM +0100, Axel Simon wrote:

...

I therefore think that keeping the number of extensions to a minimum should be a high priority. It seems that the ghc team is going overboard with the amount of extensions and their granularity that I do not believe that there will ever be another compiler since implementing all these extensions is a nightmare. The road of may extensions is leading down the road that the Haskell standards aimed to avoid: having a single implementation defining what a Haskell program can be.

I'm not sure if you're saying there should be fewer new language features implemented, less fine-grained control over which are enabled, or something else?

"Many of the new features ought to be changes to the standard, not individual language features that might or might not be implemented by various compilers." Less fine-grained control could be taken as a subset of this; consider that Haskell2010 can be understood as Haskell98 + a number of language extensions (or de-extensions in the case of n+k). I think he has a good point: having too many individual language features significantly raises the bar for what other compilers need to at least consider supporting. Even if we don't necessarily change the official standard, perhaps there should be standard packages of extensions which compilers are encouraged to support even if they don't support fine-grained extension control. - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk05BEcACgkQIn7hlCsL25VBnwCfT9nCZ5eLs4oJ3jUFHf3Tl8o1 7DwAnicvaNk6XuT0H1pZbaotzjKGoP+/ =vqzt -----END PGP SIGNATURE-----

| So, again, for this particular "extension" I suggest that the layout | rule in the standard(s) should be revised Indeed I suspect the NonDecreasingIndentation change is a proposal for Haskell Prime pocess. Or if it isn't it could be is if someone proposed it. That's the process we have in place for changing the base language. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of Axel Simon | Sent: 20 January 2011 20:23 | To: Simon Marlow | Cc: GHC users | Subject: Re: backward compatibility | | Hi Simon, | | On Jan 20, 2011, at 17:54, Simon Marlow wrote: | | > The layout fix is this change: | > | > | http://hackage.haskell.org/trac/ghc/changeset/9a82b1ffa35fa4c3927c66a1037a37... | 436cf6aac | > | > Another case where GHC was not strictly standards-compliant, and it | > was fixed by adding a flag for the extension. | > | > | > These were all bugs, but fixing them broke some code, | > unfortunately. In cases like this we *could* deprecate the | > behaviour for one major release with a warning, before removing it. | > However there's a non-trivial cost to doing so, and in some of these | > cases it would have been quite awkward to implement the warning | > (plus the cost of adding tests to make sure we actually got the | > warning right; it's easy to introduce yet more bugs). Furthermore, | > deprecations are often ignored, so sometimes the breakage is just | > delayed. | > | > Hopefully that explains why sometimes we make breaking changes. If | > the breaking change has a high enough impact, then it becomes | > worthwhile to add backwards compatibility (via warnings / | > deprecation or whatever). Of course from the point of view of the | > user, the impact is always either high (it broke) or zero (it | > didn't) :-) We have to make a judgement as to whether we should | > spend effort on backwards compatibility or not. Perhaps we're | > getting it wrong - so feedback from users is always valuable. | | I appreciate that you want to make ghc compliant to the standard. But | to be honest, it is still the case that ghc defines the de-facto | standard of what a Haskell program can be, since many programs do | employ one or more ghc-only extensions. | | In the case of the layout "bug", I think it might be worth considering | going the other way: adjusting the standard with what ghc has always | done. If I understand correctly, all my code using: | | foo = do | some computation | trace "I am here" $ do | some more computation | | will break. I use this style of coding a lot to avoid too much | indentation and thus I would have to enable this extension everywhere | (and get warnings (or errors?) for older ghcs). Even if we had 2 or 3 | implementations of Haskell 2010 in a decade, then they might not have | this extension. Furthermore, if they claim they actually do implement | the layout extension then they still might get it wrong in some subtle | way. An extension is never as well exercised as the non-extension part | of the compiler. I therefore think that keeping the number of | extensions to a minimum should be a high priority. It seems that the | ghc team is going overboard with the amount of extensions and their | granularity that I do not believe that there will ever be another | compiler since implementing all these extensions is a nightmare. The | road of may extensions is leading down the road that the Haskell | standards aimed to avoid: having a single implementation defining what | a Haskell program can be. | | So, again, for this particular "extension" I suggest that the layout | rule in the standard(s) should be revised -- if I'm mistaken, this | will not break other programs. | | Cheers, | Axel | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

On 20/01/2011 20:22, Axel Simon wrote:

In the case of the layout "bug", I think it might be worth considering going the other way: adjusting the standard with what ghc has always done. If I understand correctly, all my code using:

foo = do some computation trace "I am here" $ do some more computation

will break. I use this style of coding a lot to avoid too much indentation and thus I would have to enable this extension everywhere (and get warnings (or errors?) for older ghcs). Even if we had 2 or 3 implementations of Haskell 2010 in a decade, then they might not have this extension. Furthermore, if they claim they actually do implement the layout extension then they still might get it wrong in some subtle way. An extension is never as well exercised as the non-extension part of the compiler. I therefore think that keeping the number of extensions to a minimum should be a high priority. It seems that the ghc team is going overboard with the amount of extensions and their granularity that I do not believe that there will ever be another compiler since implementing all these extensions is a nightmare. The road of may extensions is leading down the road that the Haskell standards aimed to avoid: having a single implementation defining what a Haskell program can be.

So, again, for this particular "extension" I suggest that the layout rule in the standard(s) should be revised -- if I'm mistaken, this will not break other programs.

You've convinced me. The benefit from "fixing" GHC in this case is outweighed by the cost, I think we should revert the change (or at least enable RelaxedLayout by default), and propose the change for Haskell 2011/2012. Ian, Simon, what do you think? Cheers, Simon

On Fri, Jan 21, 2011 at 10:18:57AM +0000, Simon Marlow wrote:

On 20/01/2011 20:22, Axel Simon wrote:

...

So, again, for this particular "extension" I suggest that the layout rule in the standard(s) should be revised -- if I'm mistaken, this will not break other programs.

You've convinced me. The benefit from "fixing" GHC in this case is outweighed by the cost, I think we should revert the change (or at least enable RelaxedLayout by default), and propose the change for Haskell 2011/2012. Ian, Simon, what do you think?

You mean NondecreasingIndentation, right? (RelaxedLayout only makes a difference with explicit braces). NondecreasingIndentation is already on by default; are you suggesting we also add it to Haskell98 and Haskell2010? Thanks Ian