Re: GHC 7.4.2 on Ubuntu Trusty
I wrote:
This thread makes it clear what a mess we have inherited from the days when GHC was primarily a research compiler. Let's face it - GHC is now also a serious production compiler, and this urgently needs to be cleaned up.
hvr wrote:
Are you referring to the GMP dependency or something else? ...I'm not sure what can be done differently here.
Agreed. No, not any one of those many little details. I mean the general extreme difficulty of getting almost any version of GHC working on almost any platform, unless the two were released within a fairly short time of each other. Well, that is, not counting your wonderful ppa for Ubuntu. That is fantastic - but the dire need for it is evidence for the severity of the problem. How about this: Currently, every GHC source distribution requires no later than its own version of GHC for bootstrapping. Going backwards, that chops up the sequence of GHC versions into tiny incompatible pieces - there is no way to start with a working GHC and work backwards to an older version by compiling successively older GHC sources. If instead each GHC could be compiled using at least one subsequent version, the chain would not be broken. I.e., always provide a compatibility flag or some other reasonably simple mechanism that would enable the current GHC to compile the source code of at least the last previous released version. I realize that this might be disruptive to GHC devs, because as a compiler with a research heritage, GHC experiments with its own new features on its own source code. But as a compiler that is used commercially, some general kind of backward portability is critically important. The other direction is equally problematic. Although GHC does support bootstrapping itself from a few previous releases, porting GHC to a new platform has become harder and harder as GHC becomes more complex. I think this could become a threat to the viability of GHC - technology is always changing. As a commercial developer, I am always plagued by nagging worry about GHC portability, forward and backward. Will we always be able in the future to support code we release, or will it die someday because there will no longer exist a GHC able to compile it? Will our whole technology die someday just because we can't get GHC working on a platform we need to support? Thanks, Yitz
Excerpts from Yitzchak Gale's message of 2014-10-28 13:58:08 -0700:
How about this: Currently, every GHC source distribution requires no later than its own version of GHC for bootstrapping. Going backwards, that chops up the sequence of GHC versions into tiny incompatible pieces - there is no way to start with a working GHC and work backwards to an older version by compiling successively older GHC sources.
If instead each GHC could be compiled using at least one subsequent version, the chain would not be broken. I.e., always provide a compatibility flag or some other reasonably simple mechanism that would enable the current GHC to compile the source code of at least the last previous released version.
Here is an alternate proposal: when we make a new major version release, we should also make a minor version release of the previous series, which is prepped so that it can compile from the new major version. If it is the case that one version of the compiler can compile any other version in the same series, this would be sufficient to go backwards. Concretely, the action plan is very simple too: take 7.6 and apply as many patches as is necessary to make it compile from 7.8, and cut a release with those patches. Edward
Resurrecting this thread: My impression was that Edward's suggestion was a simple and obvious solution to the problem of previous GHC versions quickly becoming orphaned and unbuildable. But Austin thought that this thread was stuck. Would Edward's suggestion be difficult to implement for any reason? Specifically, right now would be the time to do it, and it would mean: 1. Create a 7.8.5 branch. 2. Tweak the stage 1 Haskell sources to build with 7.10 and tag 3. Create only a source tarball and upload it to the download site Thanks, Yitz On Wed, Oct 29, 2014 at 12:10 AM, Edward Z. Yang wrote:
Excerpts from Yitzchak Gale's message of 2014-10-28 13:58:08 -0700:
How about this: Currently, every GHC source distribution requires no later than its own version of GHC for bootstrapping. Going backwards, that chops up the sequence of GHC versions into tiny incompatible pieces - there is no way to start with a working GHC and work backwards to an older version by compiling successively older GHC sources.
If instead each GHC could be compiled using at least one subsequent version, the chain would not be broken. I.e., always provide a compatibility flag or some other reasonably simple mechanism that would enable the current GHC to compile the source code of at least the last previous released version.
Here is an alternate proposal: when we make a new major version release, we should also make a minor version release of the previous series, which is prepped so that it can compile from the new major version. If it is the case that one version of the compiler can compile any other version in the same series, this would be sufficient to go backwards.
Concretely, the action plan is very simple too: take 7.6 and apply as many patches as is necessary to make it compile from 7.8, and cut a release with those patches.
Edward
Hey guys, I have a local branch of ghc-7.8 which can be compiled by 7.10. The most annoying patch that needed to be backported was AMP adjustment changes. I also messed up some stuff involving LANGUAGE pragmas which I am going to go back and clean up. https://github.com/ezyang/ghc/tree/ghc-7.8 There are also some changes to hoopl, transformers and hpc (mostly because their bootstrap libraries.) Unfortunately I can't easily Phab these changes. Any suggestions for how to coordinate landing these changes? Edward Excerpts from Yitzchak Gale's message of 2014-12-28 13:38:47 -0500:
Resurrecting this thread:
My impression was that Edward's suggestion was a simple and obvious solution to the problem of previous GHC versions quickly becoming orphaned and unbuildable. But Austin thought that this thread was stuck.
Would Edward's suggestion be difficult to implement for any reason? Specifically, right now would be the time to do it, and it would mean:
1. Create a 7.8.5 branch. 2. Tweak the stage 1 Haskell sources to build with 7.10 and tag 3. Create only a source tarball and upload it to the download site
Thanks, Yitz
On Wed, Oct 29, 2014 at 12:10 AM, Edward Z. Yang wrote:
Excerpts from Yitzchak Gale's message of 2014-10-28 13:58:08 -0700:
How about this: Currently, every GHC source distribution requires no later than its own version of GHC for bootstrapping. Going backwards, that chops up the sequence of GHC versions into tiny incompatible pieces - there is no way to start with a working GHC and work backwards to an older version by compiling successively older GHC sources.
If instead each GHC could be compiled using at least one subsequent version, the chain would not be broken. I.e., always provide a compatibility flag or some other reasonably simple mechanism that would enable the current GHC to compile the source code of at least the last previous released version.
Here is an alternate proposal: when we make a new major version release, we should also make a minor version release of the previous series, which is prepped so that it can compile from the new major version. If it is the case that one version of the compiler can compile any other version in the same series, this would be sufficient to go backwards.
Concretely, the action plan is very simple too: take 7.6 and apply as many patches as is necessary to make it compile from 7.8, and cut a release with those patches.
Edward
participants (2)
-
Edward Z. Yang -
Yitzchak Gale