On 21.01.2011, at 09:10, Simon Peyton-Jones wrote:
| So, again, for this particular "extension" I suggest that the layout | rule in the standard(s) should be revised
Indeed I suspect the NonDecreasingIndentation change is a proposal for Haskell Prime pocess. Or if it isn't it could be is if someone proposed it. That's the process we have in place for changing the base language.
I have proposed to incorporate this extension into the Haskell standard. Axel
Simon
| -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of Axel Simon | Sent: 20 January 2011 20:23 | To: Simon Marlow | Cc: GHC users | Subject: Re: backward compatibility | | 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... | 436cf6aac | > | > 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 | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users