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