backward compatibility

[Simon Peyton-Jones]

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

Simon

| -----Original Message-----
| From: glasgow-haskell-users-bounces at haskell.org [mailto:glasgow-haskell-
| users-bounces at 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/9a82b1ffa35fa4c3927c66a1037a37d
| 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 at haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users