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/9a82b1ffa35fa4c3927c66a1037a37d436cf6aac
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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
