marlowsd at gmail.com
Thu Jan 20 17:54:25 CET 2011
On 20/01/2011 14:25, Kazu Yamamoto (山本和彦) wrote:
>> 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:
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:
again, it was wrong before (GHC accepted programs when it shouldn't).
The layout fix is this change:
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.
More information about the Glasgow-haskell-users