backward compatibility

[Simon Marlow]

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