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
Release/git plans
As promised, here are our plans for forthcoming GHC releases and the git switchover: - do a 7.0.2 RC as soon as possible, followed shortly by a release. Currently blocking this is a problem with Cabal that shows up on OS X 10.6, we hope to have this resolved soon. - switch the GHC repo to git (this is ready to go, we just need to flip the switch and do some work on the wiki build documentation) - switch the libraries and other repositories to git, once we have decided on the strategy (mirror or convert) for each one. - make a new stable branch for 7.2, and release 7.2.1 shortly after. So we'll be doing a 7.2.1 release much earlier than planned. Our motivation for doing this is: - the 7.0 branch is darcs, but the HEAD will be git, so the longer this situation persists the more difficult it is to merge changes. Hence we want to fork a new STABLE branch as soon as possible. - one of the fixes we need to make soon, to fix equality superclasses, is too large a change to put in the 7.0 branch. We also have some pending changes to the internal representation of coercions that will be disruptive in HEAD, and will make future merging to 7.0 difficult. - 7.0.2 should be a nice stable release, and HEAD is actually in pretty good shape right now too. FYI, the git repo is now attached to our Trac instance, so you can browse the source tree and history here: http://hackage.haskell.org/trac/ghc/browser it's not terribly fast, but it works. With git we'll be able to link directly to commits from tickets and vice-versa. The GHC git repo that we'll be using is here: http://darcs.haskell.org/ghc.git (note different from the URL for the testing repo, although it's the same repo). I'm mirroring this manually from the darcs repo, so it might lag a bit at times. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Release/git plans
Hello Simon, On Thu, Jan 20, 2011 at 9:48 AM, Simon Marlow marlo...@gmail.com wrote: ... - make a new stable branch for 7.2, and release 7.2.1 shortly after. So we'll be doing a 7.2.1 release much earlier than planned. Our motivation for doing this is: - the 7.0 branch is darcs, but the HEAD will be git, so the longer this situation persists the more difficult it is to merge changes. Hence we want to fork a new STABLE branch as soon as possible. - one of the fixes we need to make soon, to fix equality superclasses, is too large a change to put in the 7.0 branch. We also have some pending changes to the internal representation of coercions that will be disruptive in HEAD, and will make future merging to 7.0 difficult. - 7.0.2 should be a nice stable release, and HEAD is actually in pretty good shape right now too. So, given that 7.2 will be released much earlier than the normal release cycle, is there any room for anything else to get into HEAD for the 7.2 release before everything is switched? In particular I fixed up Max Bolingbroke's old compiler plugin work to be usable with the latest HEAD, and all the fundamental work is there and done, just some additional small things are needed (notably having ghc dump plugin information a la -ddump flags, and testsuite patches are about it I think.) The patch itself is pretty small and doesn't touch *too* much code, mostly adding dynamic loading and the plugin API, but it's arguably adding a 'big' feature for users of GHC to start utilizing, and perhaps a release in 7.2 would cause problems merging changes until you cut a new STABLE branch with git, like you said. It would be nice to have this in GHC 7.2, but I was thinking of eventually extending the scope of compiler plugins to allow users to write Cmm optimisations as well. It would likely be best to wait for the switch to Git and for the new code generator branch to be merged before that work happens though, but writing plugins that do Core passes seem to work well right now. The GHC git repo that we'll be using is here: http://darcs.haskell.org/ghc.git This is an incredibly minor note in my opinion (that was brought up before IIRC) but, isn't it a little strange for ghc's git repository to exist on darcs.haskell.org? Not that it's a problem, just slightly confusing I guess. -- Regards, Austin ___ 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: Release/git plans
On 20 January 2011 16:57, austin seipp a...@hacks.yi.org wrote: It would be nice to have this in GHC 7.2, but I was thinking of eventually extending the scope of compiler plugins to allow users to write Cmm optimisations as well. This would be particularly cool because Cmm optimisations in the new Hoopl framework compose extremely nicely. (And yes, obviously I would be very happy if Simon commits my plugins patches ;-)) Max ___ 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: Release/git plans
On 01/20/11 11:57, austin seipp wrote: The GHC git repo that we'll be using is here: http://darcs.haskell.org/ghc.git This is an incredibly minor note in my opinion (that was brought up before IIRC) but, isn't it a little strange for ghc's git repository to exist on darcs.haskell.org? Not that it's a problem, just slightly confusing I guess. Yes, and the commits mailing-list is still called cvs-...@haskell.org. The niceness of sounding right tends to be outweighed by the inconvenience of switching :) -Isaac ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Release/git plans
Point taken, I personally think it's rather minor although it was brought up before like I said, so perhaps others think differently. Either way, I, for one, welcome our new version control overlord. On Thu, Jan 20, 2011 at 3:09 PM, Isaac Dupree m...@isaac.cedarswampstudios.org wrote: On 01/20/11 11:57, austin seipp wrote: The GHC git repo that we'll be using is here: http://darcs.haskell.org/ghc.git This is an incredibly minor note in my opinion (that was brought up before IIRC) but, isn't it a little strange for ghc's git repository to exist on darcs.haskell.org? Not that it's a problem, just slightly confusing I guess. Yes, and the commits mailing-list is still called cvs-...@haskell.org. The niceness of sounding right tends to be outweighed by the inconvenience of switching :) -Isaac ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Regards, Austin ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Release/git plans
This is Haskell. One should abstract away the system used. Call it vcs-ghc@ and vcs.haskell.org ;-) Gruss, Christian * austin seipp a...@hacks.yi.org [20.01.2011 22:19]: Point taken, I personally think it's rather minor although it was brought up before like I said, so perhaps others think differently. Either way, I, for one, welcome our new version control overlord. On Thu, Jan 20, 2011 at 3:09 PM, Isaac Dupree m...@isaac.cedarswampstudios.org wrote: On 01/20/11 11:57, austin seipp wrote: The GHC git repo that we'll be using is here: http://darcs.haskell.org/ghc.git This is an incredibly minor note in my opinion (that was brought up before IIRC) but, isn't it a little strange for ghc's git repository to exist on darcs.haskell.org? Not that it's a problem, just slightly confusing I guess. Yes, and the commits mailing-list is still called cvs-...@haskell.org. The niceness of sounding right tends to be outweighed by the inconvenience of switching :) -Isaac ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Regards, Austin ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users pgpncMFW5zZsL.pgp Description: 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 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
