backward compatibility

[Axel Simon]

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/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.

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