GHC

This post is a response to ​Anthony's blog post about contributing to GHC, and the subsequent ​Reddit discussion. You'll find it easier to follow my comments below if you read Anthony's post first. Short summary: many of Anthony's criticisms are ... [More] accurate, but they are not easy to address, especially in a volunteer-only project. However we will do something about the feature-request process. Barrier to entry I am ashamed that GHC seems difficult to contribute to. The details don't matter; the fact that it made you feel that way is by definition bad. I'm really sorry. We should find a way to do better. An underlying issue is one of effort budget. GHC has essentially no full-timers, unlike many open-source projects. In particular, Simon Marlow and I are volunteers like everyone else, and like everyone else we have a day job. Microsoft Research generously pays Well Typed for front-line support, manifested in the heroic form of Ben and Austin, totalling around one FTE. But their effort is fully absorbed by managing releases, reviewing patches, maintaining the infrastructure, and so on. It's a real challenge to maintain a low barrier to entry for a large complex project, whose motive force is primarily volunteers. It means that any initiative will only fly if someone steps up to drive it. Technical documentation The questions of scattered and inconsistent documentation are difficult to address. GHC is twenty-five years old; it has hundreds of authors and documentation that was once accurate falls out of date. I would love it to have consistent, well-explained documentation. But I don't know how to achieve it. GHC's technical documentation is either in the code itself, or on GHC's wiki. An advantage of a wiki is that anyone can edit it. Yes, instructions and technical descriptions go out of date. Who will fix them? You, gentle reader! There is no one else. But in practice few do. Perhaps that's because such work is invisible, so no one even knows you've done it? What would make people feel "I'd really like to improve those instructions or that documentation?" I will argue for two things. First, I find Notes incredibly helpful. They live with the code, so they are less likely to go out of date. They don't mess up the flow of the code. They can be referred to from multiple places. They are the single most successful code documentation mechanism we have. (To be fair to Anthony, I don't think was complaining about Notes, just expressing surprise.) Second, I really do think that each new proposed feature needs a description, somewhere, of what it is, why it's a good thing, and as precisely as possible what its specification is. Plus perhaps some implementation notes. It's very important when reading an implementation to know what it is that the code is seeking to implement. So yes, I do frequently ask for a specification. Arc, github, phabricator, etc Personally I carry no torch for arc. I do whatever I'm told, workflow-wise. If GitHub has got a lot better since we took the Arc decision, and there's a consensus that we should shift, I'm all for it provided someone explains to me what my new workflows should be. I am absolutely in favour of reducing barriers to contribution. (Other members of the GHC team have much stronger and better informed views than me, though.) But there are costs to moving, especially if the move implies friction in the future. In particular, those that worry me most are those surrounding issue tracking. Github's issue tracker simply doesn't seem sufficient for a project as large and multi-faceted as GHC; in particular, tags as the only form of metadata is extremely limiting. One alternative would be to use Github and Trac side-by-side, but then we face the issue of conflicting ticket number spaces as both systems insist on ticket numbers of the form #NNNN. Coding style Coding style is rather a personal thing, and we have been reluctant to enforce a single uniform style. (Quite apart from the task of reformatting 150k lines of Haskell.) Personally I don't find it an obstacle to reading other people's code. Feature requests That leaves the most substantial issue that Anthony poses: the process of making a contribution. For fixing a bug, I think that (aside from the arc/Github debate) things are not too bad. On the arc/Github question, Austin has been working with the Phabricator maintainers to try to have them introduce a workflow which might be more familiar and more convenient for Github experts. But for offering a new feature, Anthony argues that the process is unacceptably arduous. There are lots of things to think about GHC has tons of features implemented by talented and motivated folk... who have since moved on. So when a new feature is proposed, my baseline guess is that I will personally be responsible for maintaining it in five years time. So I want to understand what the feature is. I want to understand how the implementation works. I want to be reasonably sure that it doesn't add a bunch of complexity to an already very complicated code base. And since any new feature adds some complexity, I want to have some confidence that the feature commands broad support -- even when it's behind a language extension flag. So actually I think it's reasonable that the process should be somewhat arduous. A new feature imposes costs on every single person who works on that code in the future. We don't really make this point explicitly, but the ​contributor guidelines for Phabricator do. It might be helpful if we articulated similar guidelines. "Any proposal needs a lightweight way to gauge broad support, then a period of constructive refinement". Indeed! What would be such a lightweight way? The trouble is that there is an enormous silent majority, and discussions are typically driven by a handful of articulate and well-informed contributors. All credit to them, but they may very well be an unrepresentative sample. I simply don't know how to gauge true broad support. There is a problem with my own personal lack of bandwidth. I am one of the main gatekeepers for some big chunks of GHC, the renamer, typechecker and optimisation passes. That is good in a way, because if GHC lacked gatekeepers, it would soon lose conceptual integrity and become a huge ball of mud. But it is bad in other ways. I review a lot of code; but not fast enough! In prioritising I am guided by my (doubtless flawed) perceptions of things that lots of people are eagerly awaiting. The same thing goes for Simon Marlow, especially in the runtime system. We both have other day jobs. Even writing this post means that I'm not reviewing someone's code. But I am acutely aware that "Simon and Simon are busy" is pretty cold comfort to someone awaiting a review. Maybe there should be a bunch of other people playing this role. That would be great. For example, Richard Eisenberg has taken responsibility for Template Haskell, which is totally fantastic. I would love to hear from people who are willing to take overall responsibility for a piece of GHC. None of this is an argument for the status quo. Simon, Ben, Austin, Herbert, and I have been talking about a rather more systematic process for new features. We'd like to learn from experience elsewhere, rather than reinvent the wheel, such as the ​Rust process. Please suggest processes that you have seen working well elsewhere. [Less]

This post is a response to ​Anthony's blog post about contributing to GHC, and the subsequent ​Reddit discussion. You'll find it easier to follow my comments below if you read Anthony's post first. Short summary: many of Anthony's criticisms are ... [More] accurate, but they are not easy to address, especially in a volunteer-only project. However we will do something about the feature-request process. Barrier to entry I am ashamed that GHC seems difficult to contribute to. The details don't matter; the fact that it made you feel that way is by definition bad. I'm really sorry. We should find a way to do better. An underlying issue is one of effort budget. GHC has essentially no full-timers, unlike many open-source projects. In particular, Simon Marlow and I are volunteers like everyone else, and like everyone else we have a day job. Microsoft Research generously pays Well Typed for front-line support, manifested in the heroic form of Ben and Austin, totalling around one FTE. But their effort is fully absorbed by managing releases, reviewing patches, maintaining the infrastructure, and so on. It's a real challenge to maintain a low barrier to entry for a large complex project, whose motive force is primarily volunteers. It means that any initiative will only fly if someone steps up to drive it. Technical documentation The questions of scattered and inconsistent documentation are difficult to address. GHC is twenty-five years old; it has hundreds of authors and documentation that was once accurate falls out of date. I would love it to have consistent, well-explained documentation. But I don't know how to achieve it. GHC's technical documentation is either in the code itself, or on GHC's wiki. An advantage of a wiki is that anyone can edit it. Yes, instructions and technical descriptions go out of date. Who will fix them? You, gentle reader! There is no one else. But in practice few do. Perhaps that's because such work is invisible, so no one even knows you've done it? What would make people feel "I'd really like to improve those instructions or that documentation?" I will argue for two things. First, I find Notes incredibly helpful. They live with the code, so they are less likely to go out of date. They don't mess up the flow of the code. They can be referred to from multiple places. They are the single most successful code documentation mechanism we have. (To be fair to Anthony, I don't think was complaining about Notes, just expressing surprise.) Second, I really do think that each new proposed feature needs a description, somewhere, of what it is, why it's a good thing, and as precisely as possible what its specification is. Plus perhaps some implementation notes. It's very important when reading an implementation to know what it is that the code is seeking to implement. So yes, I do frequently ask for a specification. Arc, github, phabricator, etc Personally I carry no torch for arc. I do whatever I'm told, workflow-wise. If GitHub has got a lot better since we took the Arc decision, and there's a consensus that we should shift, I'm all for it provided someone explains to me what my new workflows should be. I am absolutely in favour of reducing barriers to contribution. (Other members of the GHC team have much stronger and better informed views than me, though.) But there are costs to moving, especially if the move implies friction in the future. In particular, those that worry me most are those surrounding issue tracking. Github's issue tracker simply doesn't seem sufficient for a project as large and multi-faceted as GHC; in particular, tags as the only form of metadata is extremely limiting. One alternative would be to use Github and Trac side-by-side, but then we face the issue of conflicting ticket number spaces as both systems insist on ticket numbers of the form #NNNN. Coding style Coding style is rather a personal thing, and we have been reluctant to enforce a single uniform style. (Quite apart from the task of reformatting 150k lines of Haskell.) Personally I don't find it an obstacle to reading other people's code. Feature requests That leaves the most substantial issue that Anthony poses: the process of making a contribution. For fixing a bug, I think that (aside from the arc/Github debate) things are not too bad. On the arc/Github question, Austin has been working with the Phabricator maintainers to try to have them introduce a workflow which might be more familiar and more convenient for Github experts. But for offering a new feature, Anthony argues that the process is unacceptably arduous. There are lots of things to think about GHC has tons of features implemented by talented and motivated folk... who have since moved on. So when a new feature is proposed, my baseline guess is that I will personally be responsible for maintaining it in five years time. So I want to understand what the feature is. I want to understand how the implementation works. I want to be reasonably sure that it doesn't add a bunch of complexity to an already very complicated code base. And since any new feature adds some complexity, I want to have some confidence that the feature commands broad support -- even when it's behind a language extension flag. So actually I think it's reasonable that the process should be somewhat arduous. A new feature imposes costs on every single person who works on that code in the future. We don't really make this point explicitly, but the ​contributor guidelines for Phabricator do. It might be helpful if we articulated similar guidelines. "Any proposal needs a lightweight way to gauge broad support, then a period of constructive refinement". Indeed! What would be such a lightweight way? The trouble is that there is an enormous silent majority, and discussions are typically driven by a handful of articulate and well-informed contributors. All credit to them, but they may very well be an unrepresentative sample. I simply don't know how to gauge true broad support. There is a problem with my own personal lack of bandwidth. I am one of the main gatekeepers for some big chunks of GHC, the renamer, typechecker and optimisation passes. That is good in a way, because if GHC lacked gatekeepers, it would soon lose conceptual integrity and become a huge ball of mud. But it is bad in other ways. I review a lot of code; but not fast enough! In prioritising I am guided by my (doubtless flawed) perceptions of things that lots of people are eagerly awaiting. The same thing goes for Simon Marlow, especially in the runtime system. We both have other day jobs. Even writing this post means that I'm not reviewing someone's code. But I am acutely aware that "Simon and Simon are busy" is pretty cold comfort to someone awaiting a review. Maybe there should be a bunch of other people playing this role. That would be great. For example, Richard Eisenberg has taken responsibility for Template Haskell, which is totally fantastic. I would love to hear from people who are willing to take overall responsibility for a piece of GHC. None of this is an argument for the status quo. Simon, Ben, Austin, Herbert, and I have been talking about a rather more systematic process for new features. We'd like to learn from experience elsewhere, rather than reinvent the wheel, such as the ​Rust process. Please suggest processes that you have seen working well elsewhere. [Less]

This post is a response to ​Anthony's blog post about contributing to GHC, and the subsequent ​Reddit discussion. You'll find it easier to follow my comments below if you read Anthony's post first. Short summary: many of Anthony's criticisms are ... [More] accurate, but they are not easy to address, especially in a volunteer-only project. However we will do something about the feature-request process. Barrier to entry I am ashamed that GHC seems difficult to contribute to. The details don't matter; the fact that it made you feel that way is by definition bad. I'm really sorry. We should find a way to do better. An underlying issue is one of effort budget. GHC has essentially no full-timers, unlike many open-source projects. In particular, Simon Marlow and I are volunteers like everyone else, and like everyone else we have a day job. Microsoft Research generously pays Well Typed for front-line support, manifested in the heroic form of Ben and Austin, totalling around one FTE. But their effort is fully absorbed by managing releases, reviewing patches, maintaining the infrastructure, and so on. It's a real challenge to maintain a low barrier to entry for a large complex project, whose motive force is primarily volunteers. It means that any initiative will only fly if someone steps up to drive it. Technical documentation The questions of scattered and inconsistent documentation are difficult to address. GHC is twenty-five years old; it has hundreds of authors and documentation that was once accurate falls out of date. I would love it to have consistent, well-explained documentation. But I don't know how to achieve it. GHC's technical documentation is either in the code itself, or on GHC's wiki. An advantage of a wiki is that anyone can edit it. Yes, instructions and technical descriptions go out of date. Who will fix them? You, gentle reader! There is no one else. But in practice few do. Perhaps that's because such work is invisible, so no one even knows you've done it? What would make people feel "I'd really like to improve those instructions or that documentation?" I will argue for two things. First, I find Notes incredibly helpful. They live with the code, so they are less likely to go out of date. They don't mess up the flow of the code. They can be referred to from multiple places. They are the single most successful code documentation mechanism we have. (To be fair to Anthony, I don't think was complaining about Notes, just expressing surprise.) Second, I really do think that each new proposed feature needs a description, somewhere, of what it is, why it's a good thing, and as precisely as possible what its specification is. Plus perhaps some implementation notes. It's very important when reading an implementation to know what it is that the code is seeking to implement. So yes, I do frequently ask for a specification. Arc, github, phabricator, etc Personally I carry no torch for arc. I do whatever I'm told, workflow-wise. If GitHub has got a lot better since we took the Arc decision, and there's a consensus that we should shift, I'm all for it provided someone explains to me what my new workflows should be. I am absolutely in favour of reducing barriers to contribution. (Other members of the GHC team have much stronger and better informed views than me, though.) But there are costs to moving, especially if the move implies friction in the future. In particular, those that worry me most are those surrounding issue tracking. Github's issue tracker simply doesn't seem sufficient for a project as large and multi-faceted as GHC; in particular, tags as the only form of metadata is extremely limiting. One alternative would be to use Github and Trac side-by-side, but then we face the issue of conflicting ticket number spaces as both systems insist on ticket numbers of the form #NNNN. Coding style Coding style is rather a personal thing, and we have been reluctant to enforce a single uniform style. (Quite apart from the task of reformatting 150k lines of Haskell.) Personally I don't find it an obstacle to reading other people's code. Feature requests That leaves the most substantial issue that Anthony poses: the process of making a contribution. For fixing a bug, I think that (aside from the arc/Github debate) things are not too bad. On the arc/Github question, Austin has been working with the Phabricator maintainers to try to have them introduce a workflow which might be more familiar and more convenient for Github experts. But for offering a new feature, Anthony argues that the process is unacceptably arduous. There are lots of things to think about GHC has tons of features implemented by talented and motivated folk... who have since moved on. So when a new feature is proposed, my baseline guess is that I will personally be responsible for maintaining it in five years time. So I want to understand what the feature is. I want to understand how the implementation works. I want to be reasonably sure that it doesn't add a bunch of complexity to an already very complicated code base. And since any new feature adds some complexity, I want to have some confidence that the feature commands broad support -- even when it's behind a language extension flag. So actually I think it's reasonable that the process should be somewhat arduous. A new feature imposes costs on every single person who works on that code in the future. We don't really make this point explicitly, but the ​contributor guidelines for Phabricator do. It might be helpful if we articulated similar guidelines. "Any proposal needs a lightweight way to gauge broad support, then a period of constructive refinement". Indeed! What would be such a lightweight way? The trouble is that there is an enormous silent majority, and discussions are typically driven by a handful of articulate and well-informed contributors. All credit to them, but they may very well be an unrepresentative sample. I simply don't know how to gauge true broad support. There is a problem with my own personal lack of bandwidth. I am one of the main gatekeepers for some big chunks of GHC, the renamer, typechecker and optimisation passes. That is good in a way, because if GHC lacked gatekeepers, it would soon lose conceptual integrity and become a huge ball of mud. But it is bad in other ways. I review a lot of code; but not fast enough! In prioritising I am guided by my (doubtless flawed) perceptions of things that lots of people are eagerly awaiting. The same thing goes for Simon Marlow, especially in the runtime system. We both have other day jobs. Even writing this post means that I'm not reviewing someone's code. But I am acutely aware that "Simon and Simon are busy" is pretty cold comfort to someone awaiting a review. Maybe there should be a bunch of other people playing this role. That would be great. For example, Richard Eisenberg has taken responsibility for Template Haskell, which is totally fantastic. I would love to hear from people who are willing to take overall responsibility for a piece of GHC. None of this is an argument for the status quo. Simon, Ben, Austin, Herbert, and I have been talking about a rather more systematic process for new features. We'd like to learn from experience elsewhere, rather than reinvent the wheel, such as the ​Rust process. Please suggest processes that you have seen working well elsewhere. [Less]

The GHC developers are very pleased to announce the release of the first new super-major version of our Haskell compiler in six years, GHC 8.0.1. This release features dozens of exciting developments including, A more refined interface for implicit ... [More] call-stacks, allowing libraries to provide more helpful runtime error messages to users The introduction of the DuplicateRecordFields language extension, allowing multiple datatypes to declare fields of the same name Significant improvements in error message readability and content, including facilities for libraries to provide custom error messages, more aggressive warnings for fragile rewrite rules, and more helpful errors for missing imports A rewritten and substantially more thorough pattern match checker, providing more precise exhaustiveness checking in GADT pattern matches More reliable debugging information including experimental backtrace support, allowing better integration with traditional debugging tools Support for desugaring do-notation to use Applicative combinators, allowing the intuitive do notation to be used in settings which previously required the direct use of Applicative combinators The introduction of Strict and StrictData language extensions, allowing modules to be compiled with strict-by-default evaluation of bindings Great improvements in portability, including more reliable linking on Windows, a new PPC64 code generator, support for the AIX operating system, unregisterised m68k support, and significant stabilization on ARM targets A greatly improved user's guide, with beautiful and modern PDF and HTML output Introduction of type application syntax, reducing the need for proxies More complete support for pattern synonyms, including record pattern synonyms and the ability to export patterns "bundled" with a type, as you would a data constructor Support for injective type families and recursive superclass relationships An improved generics representation leveraging GHC's support for type-level literals The TypeInType extension, which unifies types and kinds, allowing GHC to reason about kind equality and enabling promotion of more constructs to the type level ...and more! A more thorough list of the changes included in this release can be found in the ​release notes, As always, we have collected various points of interest for users of previous GHC releases on the GHC 8.0 migration page, Please let us know if you encounter anything missing or unclear on this page. This release is the culmination of nearly eighteen months of effort by over one hundred contributors. We'd like to thank everyone who has contributed code, bug reports, and feedback over the past year. It's only because of their efforts that GHC continues to evolve. How to get it Both the source tarball and binary distributions for a wide variety of platforms are available here. Background Haskell is a standardized lazy functional programming language. The Glasgow Haskell Compiler (GHC) is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. Supported Platforms The list of platforms we support, and the people responsible for them, can be found on the GHC wiki Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform. Developers We welcome new contributors. Instructions on getting started with hacking on GHC are available from GHC's ​developer site. Community Resources There are mailing lists for GHC users, develpoers, and monitoring bug tracker activity; to subscribe, use the Mailman ​web interface. There are several other Haskell and GHC-related mailing lists on ​haskell.org; for the full list, see the ​lists page. Some GHC developers hang out on the #ghc and #haskell of the Freenode IRC network, too. See the ​Haskell wiki for details. Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here. [Less]

The GHC developers are very pleased to announce the release of the first new super-major version of our Haskell compiler in six years, GHC 8.0.1. This release features dozens of exciting developments including, A more refined interface for implicit ... [More] call-stacks, allowing libraries to provide more helpful runtime error messages to users The introduction of the DuplicateRecordFields language extension, allowing multiple datatypes to declare fields of the same name Significant improvements in error message readability and content, including facilities for libraries to provide custom error messages, more aggressive warnings for fragile rewrite rules, and more helpful errors for missing imports A rewritten and substantially more thorough pattern match checker, providing more precise exhaustiveness checking in GADT pattern matches More reliable debugging information including experimental backtrace support, allowing better integration with traditional debugging tools Support for desugaring do-notation to use Applicative combinators, allowing the intuitive do notation to be used in settings which previously required the direct use of Applicative combinators The introduction of Strict and StrictData language extensions, allowing modules to be compiled with strict-by-default evaluation of bindings Great improvements in portability, including more reliable linking on Windows, a new PPC64 code generator, support for the AIX operating system, unregisterised m68k support, and significant stabilization on ARM targets A greatly improved user's guide, with beautiful and modern PDF and HTML output Introduction of type application syntax, reducing the need for proxies More complete support for pattern synonyms, including record pattern synonyms and the ability to export patterns "bundled" with a type, as you would a data constructor Support for injective type families and recursive superclass relationships An improved generics representation leveraging GHC's support for type-level literals The TypeInType extension, which unifies types and kinds, allowing GHC to reason about kind equality and enabling promotion of more constructs to the type level ...and more! A more thorough list of the changes included in this release can be found in the ​release notes, As always, we have collected various points of interest for users of previous GHC releases on the GHC 8.0 migration page, Please let us know if you encounter anything missing or unclear on this page. This release is the culmination of nearly eighteen months of effort by over one hundred contributors. We'd like to thank everyone who has contributed code, bug reports, and feedback over the past year. It's only because of their efforts that GHC continues to evolve. How to get it Both the source tarball and binary distributions for a wide variety of platforms are available here. Background Haskell is a standardized lazy functional programming language. The Glasgow Haskell Compiler (GHC) is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. Supported Platforms The list of platforms we support, and the people responsible for them, can be found on the GHC wiki Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform. Developers We welcome new contributors. Instructions on getting started with hacking on GHC are available from GHC's ​developer site. Community Resources There are mailing lists for GHC users, develpoers, and monitoring bug tracker activity; to subscribe, use the Mailman ​web interface. There are several other Haskell and GHC-related mailing lists on ​haskell.org; for the full list, see the ​lists page. Some GHC developers hang out on the #ghc and #haskell of the Freenode IRC network, too. See the ​Haskell wiki for details. Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here. [Less]

The GHC developers are very pleased to announce the release of the first new super-major version of our Haskell compiler in six years, GHC 8.0.1. This release features dozens of exciting developments including, A more refined interface for implicit ... [More] call-stacks, allowing libraries to provide more helpful runtime error messages to users The introduction of the DuplicateRecordFields language extension, allowing multiple datatypes to declare fields of the same name Significant improvements in error message readability and content, including facilities for libraries to provide custom error messages, more aggressive warnings for fragile rewrite rules, and more helpful errors for missing imports A rewritten and substantially more thorough pattern match checker, providing more precise exhaustiveness checking in GADT pattern matches More reliable debugging information including experimental backtrace support, allowing better integration with traditional debugging tools Support for desugaring do-notation to use Applicative combinators, allowing the intuitive do notation to be used in settings which previously required the direct use of Applicative combinators The introduction of Strict and StrictData language extensions, allowing modules to be compiled with strict-by-default evaluation of bindings Great improvements in portability, including more reliable linking on Windows, a new PPC64 code generator, support for the AIX operating system, unregisterised m68k support, and significant stabilization on ARM targets A greatly improved user's guide, with beautiful and modern PDF and HTML output Introduction of type application syntax, reducing the need for proxies More complete support for pattern synonyms, including record pattern synonyms and the ability to export patterns "bundled" with a type, as you would a data constructor Support for injective type families and recursive superclass relationships An improved generics representation leveraging GHC's support for type-level literals The TypeInType extension, which unifies types and kinds, allowing GHC to reason about kind equality and enabling promotion of more constructs to the type level ...and more! A more thorough list of the changes included in this release can be found in the ​release notes, As always, we have collected various points of interest for users of previous GHC releases on the GHC 8.0 migration page, Please let us know if you encounter anything missing or unclear on this page. This release is the culmination of nearly eighteen months of effort by over one hundred contributors. We'd like to thank everyone who has contributed code, bug reports, and feedback over the past year. It's only because of their efforts that GHC continues to evolve. How to get it Both the source tarball and binary distributions for a wide variety of platforms are available here. Background Haskell is a standardized lazy functional programming language. The Glasgow Haskell Compiler (GHC) is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. Supported Platforms The list of platforms we support, and the people responsible for them, can be found on the GHC wiki Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform. Developers We welcome new contributors. Instructions on getting started with hacking on GHC are available from GHC's ​developer site. Community Resources There are mailing lists for GHC users, develpoers, and monitoring bug tracker activity; to subscribe, use the Mailman ​web interface. There are several other Haskell and GHC-related mailing lists on ​haskell.org; for the full list, see the ​lists page. Some GHC developers hang out on the #ghc and #haskell of the Freenode IRC network, too. See the ​Haskell wiki for details. Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here. [Less]

Hi *, Welcome for the latest entry in the GHC Weekly News, which has been somewhat irregularly scheduled - but we're as busy as ever! 8.0.1 release roadmap We're still steaming ahead on GHC 8.0.1 - any interested participants are suggested to ... [More] look at the wiki:Status/GHC-8.0.1 page, to see where we're currently at. These past few weeks have been good: we've gotten the first part of the overloaded record fields work in, and we have plans to land the kind equalities work in November. Furthermore, Simon Marlow, Peter Wortmann and Ben are working on reviewing all of the DWARF improvements, and hopefully the start of this work will land next week. But 8.0 isn't the only thing that'll be getting released... And some other minor releases In a total, unprecedented upset - we're aiming to do three GHC releases in a fairly short amount of time. 7.10.3 Ben Gamari has been working on steadily hacking away at GHC 7.10.3, and the hopes are that we'll be able to ship it soon. This will fix several dozen bugs, some of which are critical for our users. You can keep up to date by following the wiki:Status/GHC-7.10.3 page. 7.8.5 Simultaneously, your author will also be working on a GHC 7.8.5 release. While we were alerted a few months ago to this breakage, it seems rather unfortunate for the 7.8 series to remain broken on such a popular OS. Furthermore, the "Three GHC Release Policy" for many authors - to support the last three major versions of GHC - would mean that 7.8 would be broken for OS X developers for an entire year until GHC 8.2.1. Which is a pretty unfortunate circumstance. It's not expected the 7.8.5 release will contain any other fixes, however. List chatter (Over the past two weeks) Ben Gamari wrote in about switching the users guide to reStructuredText, and the TL;DR is - it's done! We'll have a beautiful new users guide for GHC 8.0.1 ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010029.html Matthew Pickering comments about the state of pattern synonym signatures, remarking that they're currently confusing, noting down some things we could possibly fix. ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010024.html Ben Gamari talked about the status of the recent DWARF work, and so far it's looking good. The needed patches are still in the review pipeline, but the hope is that they'll all be done in time for 8.0.1. ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010039.html David A Roberts wrote in to ask a question: now that we have ApplicativeDo, what about Applicative comprehensions? The responses indicate this seems like it would be a great addition. ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010062.html Richard Eisenberg sent in a status update about his work on kind equalities, and the hope is it will land shortly in November! (Your editor then hassled him for a syntax change before landing.) ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010077.html Adam Foltzer has requested another release of the GHC 7.8 series, due to it being completely broken on OS X El Capitan. Expect more news on this soon. ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010078.html Erik de Castro Lopo has recently been working with LLVM, and decided to publish his automation so interested GHC hackers could keep up to date and try new LLVMs easily. ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010086.html Noteworthy commits (Over the past two weeks) Commit 4fd6207ec6960c429e6a1bcbe0282f625010f52a - Move the users guide to reStructured Text. Commit 6cde981a8788b225819be28659caddc35b77972d - Make GHC.Generics capable of handling unboxed tuples. Commit 0eb8fcd94b29ee9997b386e64203037bdf2aaa04 - Enable Enumeration is empty warnings for Integer Commit 620fc6f909cd6e51b5613454097ec1c9f323839a - Make Windows linker more robust to unknown sections Commit 5d841108acef950fed6a5e608ac9b18e7431aa87 - Add short library names support to the Windows linker Commit f8fbf385b879fe177409a25cc9499275ea3dc45d - Reinstate monomorphism-restriction warnings Commit dcc342870b4d8a739ccbed3ae26e84dcc3579914 - Don't inline/apply other rules when simplifying a rule RHS. Commit dec5cd4085488686b5ed50bb26ccbc0ba7b645ec - base: Add forkOSWithUnmask Commit e8c8173923302268ef950c3b21e276779e45ac83 - Allow arr ∧ (first ∨ (*)) as minimal definition of Arrow instance Commit 29310b622801733e1b29a9a61988406872db13ca - Switch to LLVM version 3.7 Commit 04e8366608fee4f5e3358acc855bc6f556c3f508 - ELF/x86_64: map object file sections separately into the low 2GB Commit b1884b0e62f62e3c0859515c4137124ab0c9560e - Implement DuplicateRecordFields Commit 75492e7467ff962f2f2e29e5c8b2c588c94ae8a7 - Add typed holes support in Template Haskell. Commit 6a8ca65032c6b3ed61b5378765e70120083cf5da - Allow left ∨ (+++) as minimal definition of ArrowChoice instance Closed tickets (Over the past two weeks) #10392, #7883, #10475, #10745, #10926, #9238, #10700, #10810, #10342, #365(!), #10361, #10929, #10563, #9907, #10513, #10868, #10932, #8920, #10516, #10416, #5966, #8335, #10520, #10687, #10571, #9058, #10939, #10938, #9590, #10949, #10153, #10947, #10948, #10936, #1883, #5289, #10733, #10950, #10611, #10959, #10960, #10831, #10796, #10890, #8010, #10216, #10965, #10953, #10964, #10931, #10714, #10888, #10633, #8652, #3971, #10882, #10977, #10267, and #10911. [Less]

Hi *, Welcome for the latest entry in the GHC Weekly News, which has been somewhat irregularly scheduled - but we're as busy as ever! 8.0.1 release roadmap We're still steaming ahead on GHC 8.0.1 - any interested participants are suggested to ... [More] look at the wiki:Status/GHC-8.0.1 page, to see where we're currently at. These past few weeks have been good: we've gotten the first part of the overloaded record fields work in, and we have plans to land the kind equalities work in November. Furthermore, Simon Marlow, Peter Wortmann and Ben are working on reviewing all of the DWARF improvements, and hopefully the start of this work will land next week. But 8.0 isn't the only thing that'll be getting released... And some other minor releases In a total, unprecedented upset - we're aiming to do three GHC releases in a fairly short amount of time. 7.10.3 Ben Gamari has been working on steadily hacking away at GHC 7.10.3, and the hopes are that we'll be able to ship it soon. This will fix several dozen bugs, some of which are critical for our users. You can keep up to date by following the wiki:Status/GHC-7.10.3 page. 7.8.5 Simultaneously, your author will also be working on a GHC 7.8.5 release. While we were alerted a few months ago to this breakage, it seems rather unfortunate for the 7.8 series to remain broken on such a popular OS. Furthermore, the "Three GHC Release Policy" for many authors - to support the last three major versions of GHC - would mean that 7.8 would be broken for OS X developers for an entire year until GHC 8.2.1. Which is a pretty unfortunate circumstance. It's not expected the 7.8.5 release will contain any other fixes, however. List chatter (Over the past two weeks) Ben Gamari wrote in about switching the users guide to reStructuredText, and the TL;DR is - it's done! We'll have a beautiful new users guide for GHC 8.0.1 ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010029.html Matthew Pickering comments about the state of pattern synonym signatures, remarking that they're currently confusing, noting down some things we could possibly fix. ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010024.html Ben Gamari talked about the status of the recent DWARF work, and so far it's looking good. The needed patches are still in the review pipeline, but the hope is that they'll all be done in time for 8.0.1. ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010039.html David A Roberts wrote in to ask a question: now that we have ApplicativeDo, what about Applicative comprehensions? The responses indicate this seems like it would be a great addition. ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010062.html Richard Eisenberg sent in a status update about his work on kind equalities, and the hope is it will land shortly in November! (Your editor then hassled him for a syntax change before landing.) ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010077.html Adam Foltzer has requested another release of the GHC 7.8 series, due to it being completely broken on OS X El Capitan. Expect more news on this soon. ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010078.html Erik de Castro Lopo has recently been working with LLVM, and decided to publish his automation so interested GHC hackers could keep up to date and try new LLVMs easily. ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010086.html Noteworthy commits (Over the past two weeks) Commit 4fd6207ec6960c429e6a1bcbe0282f625010f52a - Move the users guide to reStructured Text. Commit 6cde981a8788b225819be28659caddc35b77972d - Make GHC.Generics capable of handling unboxed tuples. Commit 0eb8fcd94b29ee9997b386e64203037bdf2aaa04 - Enable Enumeration is empty warnings for Integer Commit 620fc6f909cd6e51b5613454097ec1c9f323839a - Make Windows linker more robust to unknown sections Commit 5d841108acef950fed6a5e608ac9b18e7431aa87 - Add short library names support to the Windows linker Commit f8fbf385b879fe177409a25cc9499275ea3dc45d - Reinstate monomorphism-restriction warnings Commit dcc342870b4d8a739ccbed3ae26e84dcc3579914 - Don't inline/apply other rules when simplifying a rule RHS. Commit dec5cd4085488686b5ed50bb26ccbc0ba7b645ec - base: Add forkOSWithUnmask Commit e8c8173923302268ef950c3b21e276779e45ac83 - Allow arr ∧ (first ∨ (*)) as minimal definition of Arrow instance Commit 29310b622801733e1b29a9a61988406872db13ca - Switch to LLVM version 3.7 Commit 04e8366608fee4f5e3358acc855bc6f556c3f508 - ELF/x86_64: map object file sections separately into the low 2GB Commit b1884b0e62f62e3c0859515c4137124ab0c9560e - Implement DuplicateRecordFields Commit 75492e7467ff962f2f2e29e5c8b2c588c94ae8a7 - Add typed holes support in Template Haskell. Commit 6a8ca65032c6b3ed61b5378765e70120083cf5da - Allow left ∨ (+++) as minimal definition of ArrowChoice instance Closed tickets (Over the past two weeks) #10392, #7883, #10475, #10745, #10926, #9238, #10700, #10810, #10342, #365(!), #10361, #10929, #10563, #9907, #10513, #10868, #10932, #8920, #10516, #10416, #5966, #8335, #10520, #10687, #10571, #9058, #10939, #10938, #9590, #10949, #10153, #10947, #10948, #10936, #1883, #5289, #10733, #10950, #10611, #10959, #10960, #10831, #10796, #10890, #8010, #10216, #10965, #10953, #10964, #10931, #10714, #10888, #10633, #8652, #3971, #10882, #10977, #10267, and #10911. [Less]

Hi *, Welcome for the latest entry in the GHC Weekly News, which has been somewhat irregularly scheduled - but we're as busy as ever! 8.0.1 release roadmap We're still steaming ahead on GHC 8.0.1 - any interested participants are suggested to ... [More] look at the wiki:Status/GHC-8.0.1 page, to see where we're currently at. These past few weeks have been good: we've gotten the first part of the overloaded record fields work in, and we have plans to land the kind equalities work in November. Furthermore, Simon Marlow, Peter Wortmann and Ben are working on reviewing all of the DWARF improvements, and hopefully the start of this work will land next week. But 8.0 isn't the only thing that'll be getting released... And some other minor releases In a total, unprecedented upset - we're aiming to do three GHC releases in a fairly short amount of time. 7.10.3 Ben Gamari has been working on steadily hacking away at GHC 7.10.3, and the hopes are that we'll be able to ship it soon. This will fix several dozen bugs, some of which are critical for our users. You can keep up to date by following the wiki:Status/GHC-7.10.3 page. 7.8.5 Simultaneously, your author will also be working on a GHC 7.8.5 release. While we were alerted a few months ago to this breakage, it seems rather unfortunate for the 7.8 series to remain broken on such a popular OS. Furthermore, the "Three GHC Release Policy" for many authors - to support the last three major versions of GHC - would mean that 7.8 would be broken for OS X developers for an entire year until GHC 8.2.1. Which is a pretty unfortunate circumstance. It's not expected the 7.8.5 release will contain any other fixes, however. List chatter (Over the past two weeks) Ben Gamari wrote in about switching the users guide to reStructuredText, and the TL;DR is - it's done! We'll have a beautiful new users guide for GHC 8.0.1 ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010029.html Matthew Pickering comments about the state of pattern synonym signatures, remarking that they're currently confusing, noting down some things we could possibly fix. ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010024.html Ben Gamari talked about the status of the recent DWARF work, and so far it's looking good. The needed patches are still in the review pipeline, but the hope is that they'll all be done in time for 8.0.1. ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010039.html David A Roberts wrote in to ask a question: now that we have ApplicativeDo, what about Applicative comprehensions? The responses indicate this seems like it would be a great addition. ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010062.html Richard Eisenberg sent in a status update about his work on kind equalities, and the hope is it will land shortly in November! (Your editor then hassled him for a syntax change before landing.) ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010077.html Adam Foltzer has requested another release of the GHC 7.8 series, due to it being completely broken on OS X El Capitan. Expect more news on this soon. ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010078.html Erik de Castro Lopo has recently been working with LLVM, and decided to publish his automation so interested GHC hackers could keep up to date and try new LLVMs easily. ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010086.html Noteworthy commits (Over the past two weeks) Commit 4fd6207ec6960c429e6a1bcbe0282f625010f52a - Move the users guide to reStructured Text. Commit 6cde981a8788b225819be28659caddc35b77972d - Make GHC.Generics capable of handling unboxed tuples. Commit 0eb8fcd94b29ee9997b386e64203037bdf2aaa04 - Enable Enumeration is empty warnings for Integer Commit 620fc6f909cd6e51b5613454097ec1c9f323839a - Make Windows linker more robust to unknown sections Commit 5d841108acef950fed6a5e608ac9b18e7431aa87 - Add short library names support to the Windows linker Commit f8fbf385b879fe177409a25cc9499275ea3dc45d - Reinstate monomorphism-restriction warnings Commit dcc342870b4d8a739ccbed3ae26e84dcc3579914 - Don't inline/apply other rules when simplifying a rule RHS. Commit dec5cd4085488686b5ed50bb26ccbc0ba7b645ec - base: Add forkOSWithUnmask Commit e8c8173923302268ef950c3b21e276779e45ac83 - Allow arr ∧ (first ∨ (*)) as minimal definition of Arrow instance Commit 29310b622801733e1b29a9a61988406872db13ca - Switch to LLVM version 3.7 Commit 04e8366608fee4f5e3358acc855bc6f556c3f508 - ELF/x86_64: map object file sections separately into the low 2GB Commit b1884b0e62f62e3c0859515c4137124ab0c9560e - Implement DuplicateRecordFields Commit 75492e7467ff962f2f2e29e5c8b2c588c94ae8a7 - Add typed holes support in Template Haskell. Commit 6a8ca65032c6b3ed61b5378765e70120083cf5da - Allow left ∨ (+++) as minimal definition of ArrowChoice instance Closed tickets (Over the past two weeks) #10392, #7883, #10475, #10745, #10926, #9238, #10700, #10810, #10342, #365(!), #10361, #10929, #10563, #9907, #10513, #10868, #10932, #8920, #10516, #10416, #5966, #8335, #10520, #10687, #10571, #9058, #10939, #10938, #9590, #10949, #10153, #10947, #10948, #10936, #1883, #5289, #10733, #10950, #10611, #10959, #10960, #10831, #10796, #10890, #8010, #10216, #10965, #10953, #10964, #10931, #10714, #10888, #10633, #8652, #3971, #10882, #10977, #10267, and #10911. [Less]

Hi *, Welcome for the latest entry in the GHC Weekly News, which has been somewhat irregularly scheduled - but we're as busy as ever! 8.0.1 release roadmap We're still steaming ahead on GHC 8.0.1 - any interested participants are suggested to ... [More] look at the wiki:Status/GHC-8.0.1 page, to see where we're currently at. These past few weeks have been good: we've gotten the first part of the overloaded record fields work in, and we have plans to land the kind equalities work in November. Furthermore, Simon Marlow, Peter Wortmann and Ben are working on reviewing all of the DWARF improvements, and hopefully the start of this work will land next week. But 8.0 isn't the only thing that'll be getting released... And some other minor releases In a total, unprecedented upset - we're aiming to do three GHC releases in a fairly short amount of time. 7.10.3 Ben Gamari has been working on steadily hacking away at GHC 7.10.3, and the hopes are that we'll be able to ship it soon. This will fix several dozen bugs, some of which are critical for our users. You can keep up to date by following the wiki:Status/GHC-7.10.3 page. 7.8.5 Simultaneously, your author will also be working on a GHC 7.8.5 release. While we were alerted a few months ago to this breakage, it seems rather unfortunate for the 7.8 series to remain broken on such a popular OS. Furthermore, the "Three GHC Release Policy" for many authors - to support the last three major versions of GHC - would mean that 7.8 would be broken for OS X developers for an entire year until GHC 8.2.1. Which is a pretty unfortunate circumstance. It's not expected the 7.8.5 release will contain any other fixes, however. List chatter (Over the past two weeks) Ben Gamari wrote in about switching the users guide to reStructuredText, and the TL;DR is - it's done! We'll have a beautiful new users guide for GHC 8.0.1 ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010029.html Matthew Pickering comments about the state of pattern synonym signatures, remarking that they're currently confusing, noting down some things we could possibly fix. ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010024.html Ben Gamari talked about the status of the recent DWARF work, and so far it's looking good. The needed patches are still in the review pipeline, but the hope is that they'll all be done in time for 8.0.1. ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010039.html David A Roberts wrote in to ask a question: now that we have ApplicativeDo, what about Applicative comprehensions? The responses indicate this seems like it would be a great addition. ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010062.html Richard Eisenberg sent in a status update about his work on kind equalities, and the hope is it will land shortly in November! (Your editor then hassled him for a syntax change before landing.) ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010077.html Adam Foltzer has requested another release of the GHC 7.8 series, due to it being completely broken on OS X El Capitan. Expect more news on this soon. ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010078.html Erik de Castro Lopo has recently been working with LLVM, and decided to publish his automation so interested GHC hackers could keep up to date and try new LLVMs easily. ​https://mail.haskell.org/pipermail/ghc-devs/2015-October/010086.html Noteworthy commits (Over the past two weeks) Commit 4fd6207ec6960c429e6a1bcbe0282f625010f52a - Move the users guide to reStructured Text. Commit 6cde981a8788b225819be28659caddc35b77972d - Make GHC.Generics capable of handling unboxed tuples. Commit 0eb8fcd94b29ee9997b386e64203037bdf2aaa04 - Enable Enumeration is empty warnings for Integer Commit 620fc6f909cd6e51b5613454097ec1c9f323839a - Make Windows linker more robust to unknown sections Commit 5d841108acef950fed6a5e608ac9b18e7431aa87 - Add short library names support to the Windows linker Commit f8fbf385b879fe177409a25cc9499275ea3dc45d - Reinstate monomorphism-restriction warnings Commit dcc342870b4d8a739ccbed3ae26e84dcc3579914 - Don't inline/apply other rules when simplifying a rule RHS. Commit dec5cd4085488686b5ed50bb26ccbc0ba7b645ec - base: Add forkOSWithUnmask Commit e8c8173923302268ef950c3b21e276779e45ac83 - Allow arr ∧ (first ∨ (*)) as minimal definition of Arrow instance Commit 29310b622801733e1b29a9a61988406872db13ca - Switch to LLVM version 3.7 Commit 04e8366608fee4f5e3358acc855bc6f556c3f508 - ELF/x86_64: map object file sections separately into the low 2GB Commit b1884b0e62f62e3c0859515c4137124ab0c9560e - Implement DuplicateRecordFields Commit 75492e7467ff962f2f2e29e5c8b2c588c94ae8a7 - Add typed holes support in Template Haskell. Commit 6a8ca65032c6b3ed61b5378765e70120083cf5da - Allow left ∨ (+++) as minimal definition of ArrowChoice instance Closed tickets (Over the past two weeks) #10392, #7883, #10475, #10745, #10926, #9238, #10700, #10810, #10342, #365(!), #10361, #10929, #10563, #9907, #10513, #10868, #10932, #8920, #10516, #10416, #5966, #8335, #10520, #10687, #10571, #9058, #10939, #10938, #9590, #10949, #10153, #10947, #10948, #10936, #1883, #5289, #10733, #10950, #10611, #10959, #10960, #10831, #10796, #10890, #8010, #10216, #10965, #10953, #10964, #10931, #10714, #10888, #10633, #8652, #3971, #10882, #10977, #10267, and #10911. [Less]