backward compatibility

Axel Simon Axel.Simon at in.tum.de
Fri Jan 21 09:42:05 CET 2011


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




More information about the Glasgow-haskell-users mailing list