Re: backward compatibility
On 21/01/2011 13:12, Ian Lynagh wrote: On Fri, Jan 21, 2011 at 10:18:57AM +, Simon Marlow wrote: On 20/01/2011 20:22, Axel Simon wrote: 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. You've convinced me. The benefit from fixing GHC in this case is outweighed by the cost, I think we should revert the change (or at least enable RelaxedLayout by default), and propose the change for Haskell 2011/2012. Ian, Simon, what do you think? You mean NondecreasingIndentation, right? (RelaxedLayout only makes a difference with explicit braces). NondecreasingIndentation is already on by default; are you suggesting we also add it to Haskell98 and Haskell2010? Sorry, I'm confused. We don't seem to have any docs for NondecreasingIndentation, do we? So was the code that broke using Haskell2010 or Haskell98? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: backward compatibility
| 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-boun...@haskell.org [mailto:glasgow-haskell- | users-boun...@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@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: backward compatibility
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-boun...@haskell.org [mailto:glasgow-haskell- | users-boun...@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@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: backward compatibility
On 20/01/2011 20:22, Axel Simon wrote: 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. You've convinced me. The benefit from fixing GHC in this case is outweighed by the cost, I think we should revert the change (or at least enable RelaxedLayout by default), and propose the change for Haskell 2011/2012. Ian, Simon, what do you think? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: backward compatibility
| You've convinced me. The benefit from fixing GHC in this case is | outweighed by the cost, I think we should revert the change (or at least | enable RelaxedLayout by default), and propose the change for Haskell | 2011/2012. Ian, Simon, what do you think? I'm ok with that ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: backward compatibility
On Fri, Jan 21, 2011 at 10:18:57AM +, Simon Marlow wrote: On 20/01/2011 20:22, Axel Simon wrote: 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. You've convinced me. The benefit from fixing GHC in this case is outweighed by the cost, I think we should revert the change (or at least enable RelaxedLayout by default), and propose the change for Haskell 2011/2012. Ian, Simon, what do you think? You mean NondecreasingIndentation, right? (RelaxedLayout only makes a difference with explicit braces). NondecreasingIndentation is already on by default; are you suggesting we also add it to Haskell98 and Haskell2010? Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: backward compatibility
On 20 January 2011 02:47, John Meacham j...@repetae.net wrote: Allowing this was a specific feature that was included in ghc on purpose (as well as the relaxed if/then layout rule in do statements) So this is definitely a regression. Ian split this out in this patch: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitdiff;h=20101124220507-3fd76-26e1672e163f309adf8992fd402df1214b7db6dd.gz (You can see the tests here: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=testsuite;a=darcs_commitdiff;h=20101125012715-3fd76-fb009b5a590d609380c894261e651710f86c0430.gz) However, when he split it out he made sure that it was still turned on by default unless the package explicitly requested Haskell 98 or 2010 compatibility (with -XHaskell98 or -XHaskell2010) - so I'm not sure why it should cause breakage. I don't have a HEAD build around so I can't find out for myself at the moment. Cheers, Max ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: backward compatibility
On Thu, Jan 20, 2011 at 08:14:29AM +, Max Bolingbroke wrote: On 20 January 2011 02:47, John Meacham j...@repetae.net wrote: Allowing this was a specific feature that was included in ghc on purpose (as well as the relaxed if/then layout rule in do statements) So this is definitely a regression. Ian split this out in this patch: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitdiff;h=20101124220507-3fd76-26e1672e163f309adf8992fd402df1214b7db6dd.gz (You can see the tests here: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=testsuite;a=darcs_commitdiff;h=20101125012715-3fd76-fb009b5a590d609380c894261e651710f86c0430.gz) However, when he split it out he made sure that it was still turned on by default unless the package explicitly requested Haskell 98 or 2010 compatibility (with -XHaskell98 or -XHaskell2010) - so I'm not sure why it should cause breakage. I don't have a HEAD build around so I can't find out for myself at the moment. Yes, it's still on in GHC by default, but Cabal specifies Haskell98 if a language isn't given in the .cabal file. network probably wants to give NondecreasingIndentation as an extension if impl(ghc = 7.1). Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: backward compatibility
Hello, Yes, it's still on in GHC by default, but Cabal specifies Haskell98 if a language isn't given in the .cabal file. network probably wants to give NondecreasingIndentation as an extension if impl(ghc = 7.1). I'm not asking how to fix packages. Actually the layout of the network package on github has been fixed today. I'm asking why GHC breaks backward compatibility (e.g. FlexibleInstances and BangPatterns) and why maintainers of packages should do boring fixes. What are benefits of such overhead? --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: backward compatibility
Am Donnerstag, den 20.01.2011, 23:25 +0900 schrieb 山本和彦: I'm asking why GHC breaks backward compatibility (e.g. FlexibleInstances and BangPatterns) and why maintainers of packages should do boring fixes. What are benefits of such overhead? Hi, what are the changes in GHC wrt. FlexibleInstances and BangPatterns? Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: backward compatibility
Simon Marlow wrote: 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. From the point of view of darcs, which is usually trying to support 2 or 3 GHC versions at a time, one cycle of deprecation makes life a lot simpler. We do look at warnings and try to fix them, but it's nicer not to have to do so in a real hurry. Cheers, Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: backward compatibility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/20/11 12:09 , Sittampalam, Ganesh wrote: Simon Marlow wrote: 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. From the point of view of darcs, which is usually trying to support 2 or 3 GHC versions at a time, one cycle of deprecation makes life a lot simpler. We do look at warnings and try to fix them, but it's nicer not to have to do so in a real hurry. And of the Haskell Platform, etc. Think of it as the price of failing to avoid success. - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk04bpsACgkQIn7hlCsL25Wh2QCgydcO3kZGxRTePJvp+HvnZloI r/wAn0YIv8ZqN6ZS9WNMvaH86F3AHZgl =m18O -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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/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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: backward compatibility
On Thu, Jan 20, 2011 at 05:09:58PM -, Sittampalam, Ganesh wrote: From the point of view of darcs, which is usually trying to support 2 or 3 GHC versions at a time, one cycle of deprecation makes life a lot simpler. We do look at warnings and try to fix them, but it's nicer not to have to do so in a real hurry. Note that in 2 of these cases (FlexibleInstances and BangPatterns), once the package is fixed for 7.2 it will still work with older versions. And actually, Cabal ought to accept NondecreasingIndentation (and do nothing) for older GHCs too; I've just written a patch to fix that. So these aren't changes where you need anything like ifdefs to support both before and after. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: backward compatibility
On Thu, Jan 20, 2011 at 09:22:37PM +0100, Axel Simon wrote: 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. Anyone can propose language changes - the process is described here: http://hackage.haskell.org/trac/haskell-prime/wiki/Process 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. I'm not sure if you're saying there should be fewer new language features implemented, less fine-grained control over which are enabled, or something else? Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: backward compatibility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/20/11 21:12 , Ian Lynagh wrote: On Thu, Jan 20, 2011 at 09:22:37PM +0100, Axel Simon wrote: 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. I'm not sure if you're saying there should be fewer new language features implemented, less fine-grained control over which are enabled, or something else? Many of the new features ought to be changes to the standard, not individual language features that might or might not be implemented by various compilers. Less fine-grained control could be taken as a subset of this; consider that Haskell2010 can be understood as Haskell98 + a number of language extensions (or de-extensions in the case of n+k). I think he has a good point: having too many individual language features significantly raises the bar for what other compilers need to at least consider supporting. Even if we don't necessarily change the official standard, perhaps there should be standard packages of extensions which compilers are encouraged to support even if they don't support fine-grained extension control. - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk05BEcACgkQIn7hlCsL25VBnwCfT9nCZ5eLs4oJ3jUFHf3Tl8o1 7DwAnicvaNk6XuT0H1pZbaotzjKGoP+/ =vqzt -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: backward compatibility
On 21.01.2011, at 03:12, Ian Lynagh wrote: On Thu, Jan 20, 2011 at 09:22:37PM +0100, Axel Simon wrote: 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. Anyone can propose language changes - the process is described here: http://hackage.haskell.org/trac/haskell-prime/wiki/Process 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. I'm not sure if you're saying there should be fewer new language features implemented, less fine-grained control over which are enabled, or something else? I agree that new language features is required to make Haskell a research platform. So it would be awkward to try to stop people from adding new language features. I don't mind if highly experimental language features come in many varieties (i.e. with fine-grained control about what is allowed). I'm more concerned about standard extensions that many (even most) people use somewhere in their projects. I get the feeling that these get split up into too many individual language features which will make it difficult for other compilers to implement the extension and the switched-off extension correctly. Haskell 2010 is going into the right direction in making some of these features mandatory which means that they become language features that you can't switch them off anymore. This makes it more likely that future compilers can implement a comprehensive Haskell language. So yes, less fine-grained control for features people use often. The layout rule seems to be one extension that can go into the report (both 98 and 2010) without breaking any program. If this is really so, then I think it is easiest for compiler writer and users if such a change is made to the report. I think only very few language features qualify for going directly into the reports since most of them can break programs. Hope this clarifies my opinion, Cheers, Axel Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
backward compatibility
Hello, I have been using GHC HEAD for some months and am suffering from the breaks of backward compatibility. 1) MANY packages cannot be complied with GHC HEAD because of lack of FlexibleInstances and BangPatterns. 2) The network package on github cannot be compiled because the layout handling of GHC HEAD became more severe. For instance, here is such code from Network/Socket.hsc. allocaBytes (2 * sizeOf (1 :: CInt)) $ \ fdArr - do _ - throwSocketErrorIfMinus1Retry socketpair $ c_socketpair (packFamily family) (packSocketType stype) protocol fdArr Of course, indentation is necessary before _. But this can be compiled with GHC 7.0.1 but cannot with GHC HEAD. I sent feedback to some maintainers of packages. Some quickly fixed it and registered it again. But others did not respond. That is reality. So, my question is why GHC HEAD does not maintain backward compatibility? What are befits for giving it up? --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: backward compatibility
In my case I omitted BangPatterns from the pragma by accident and was thankful for the update. One slight benefit of the strict requirement of correct pragma is it's easier to survey Hackage to see how features are used, their popularity, and inform language design (ex: Garrett Morris's Haskell Symposium paper). Cheers, Thomas On Wed, Jan 19, 2011 at 6:32 PM, Kazu Yamamoto k...@iij.ad.jp wrote: Hello, I have been using GHC HEAD for some months and am suffering from the breaks of backward compatibility. 1) MANY packages cannot be complied with GHC HEAD because of lack of FlexibleInstances and BangPatterns. 2) The network package on github cannot be compiled because the layout handling of GHC HEAD became more severe. For instance, here is such code from Network/Socket.hsc. allocaBytes (2 * sizeOf (1 :: CInt)) $ \ fdArr - do _ - throwSocketErrorIfMinus1Retry socketpair $ c_socketpair (packFamily family) (packSocketType stype) protocol fdArr Of course, indentation is necessary before _. But this can be compiled with GHC 7.0.1 but cannot with GHC HEAD. I sent feedback to some maintainers of packages. Some quickly fixed it and registered it again. But others did not respond. That is reality. So, my question is why GHC HEAD does not maintain backward compatibility? What are befits for giving it up? --Kazu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: backward compatibility
On Wed, Jan 19, 2011 at 6:32 PM, Kazu Yamamoto k...@iij.ad.jp wrote: Hello, I have been using GHC HEAD for some months and am suffering from the breaks of backward compatibility. 1) MANY packages cannot be complied with GHC HEAD because of lack of FlexibleInstances and BangPatterns. 2) The network package on github cannot be compiled because the layout handling of GHC HEAD became more severe. For instance, here is such code from Network/Socket.hsc. allocaBytes (2 * sizeOf (1 :: CInt)) $ \ fdArr - do _ - throwSocketErrorIfMinus1Retry socketpair $ c_socketpair (packFamily family) (packSocketType stype) protocol fdArr Allowing this was a specific feature that was included in ghc on purpose (as well as the relaxed if/then layout rule in do statements) So this is definitely a regression. John ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
