- ghc-devs - Haskell.org

[ANNOUNCE] GHC 8.0.1 is available!
by Ben Gamari 27 May '16

27 May '16

=============================================== The Glasgow Haskell Compiler -- version 8.0.1 =============================================== 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 call-stacks, allowing libraries to provide more helpful runtime error messages to users * The introduction of the DuplicateRecordFields language extension, allowing multiple record types 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, https://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/8.0.1-notes.… As always, we have collected various points of interest for users of previous GHC releases on the GHC 8.0 migration page, https://ghc.haskell.org/trac/ghc/wiki/Migration/8.0 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 at, http://www.haskell.org/ghc/ 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 http://ghc.haskell.org/trac/ghc/wiki/Platforms Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on getting started with hacking on GHC are available from GHC's developer site, http://ghc.haskell.org/trac/ghc/ Community Resources ~~~~~~~~~~~~~~~~~~~ There are mailing lists for GHC users, develpoers, and monitoring bug tracker activity; to subscribe, use the web interfaces at http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other Haskell and GHC-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Some GHC developers hang out on the #ghc and #haskell of the Freenode IRC network, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

2 1

Optimizing "counting" GADTs
by David Feuer 25 May '16

25 May '16

I've started a wiki page, https://ghc.haskell.org/trac/ghc/wiki/OptimizeCountingGADTs , to consider optimizing GADTs that look like natural numbers but that possibly have "heavy zeros". Please take a look.

1 0

Re: instances for closed type families
by Ryan Scott 25 May '16

25 May '16

Simon is right, you cannot use a type family as an instance head. But why do you need to? Typically, if you're deriving a Data instance that involves type families, the type families would be inside another data type. A real-world example is HsBindLR [1]: data HsBindLR idL idR = FunBind { ... bind_fvs :: PostRn idL NameSet, ... } | ... where PostRn is a type family [2]. Now, you can't simply derive Data for HsBindLR, because GHC has no way of knowing what PostRn will evaluate to! But you can use standalone deriving to get what you want: deriving instance (Data (PostRn idL NameSet), ...) => Data (HsBindLR idL idR) And in fact, this is what GHC does [3], using a convenient type synonyms for the long, sprawling context you need [4]. So in your example, while you can't directly create a Data instance for NameOrRdrName itself, you can quite easily create Data instances for anything that might use NameOrRdrName. Does that work for your use cases? Ryan S. ----- [1] http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa3… [2] http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa3… [3] http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa3… [4] http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa3…

2 3

will close some of the cost-center tickets - how to compare .perf outputs?
by Ömer Sinan Ağacan 25 May '16

25 May '16

I'm trying to write some tests for some profiling-related tickets and I don't understand how do I compare .prof outputs. Can anyone help? I tried generating a .prof.sample and it worked, but somehow if I delete a random line from .prof.sample, my test still succeeds! If I delete the whole file or keep the file but delete the contents, it fails. I have no idea what's going on. Any ideas? Thanks

1 0

instances for closed type families
by Alan & Kim Zimmerman 25 May '16

25 May '16

I am working on https://ghc.haskell.org/trac/ghc/ticket/12105, and have a type to ensure that the `HsMatchContext` has either a `RdrName` or a `Name`, not an `Id`. type family NameOrRdrName id where NameOrRdrName Id = Name NameOrRdrName Name = Name NameOrRdrName RdrName = RdrName Is there any way to declare `Data` and `OutputableBndr` instances for this? Without it I am having to do something like instance (OutputableBndr name, OutputableBndr (NameOrRdrName name)) => Outputable (HsDecl name) where which requires UndecidableInstances. I get compiler/hsSyn/PlaceHolder.hs:114:19: Illegal type synonym family application in instance: NameOrRdrName id In the stand-alone deriving instance for ‘Data (NameOrRdrName id)’ for the parameterised version and compiler/hsSyn/PlaceHolder.hs:115:19: Illegal type synonym family application in instance: NameOrRdrName RdrName In the stand-alone deriving instance for ‘Data (NameOrRdrName RdrName)’ for the one specific to `RdrName`. Regards Alan

2 2

Build fails
by Simon Peyton Jones 23 May '16

23 May '16

Binary.readBinMem: decompression failed What’s going on? This is a clean validate on Linux. I have done git pull, git submodule update –recursive –init Simon cd libraries && sh gen_contents_index --intree grep: ../bin-package-db/bin-package-db.cabal: No such file or directory grep: ../integer-gmp2/integer-gmp.cabal: No such file or directory haddock: internal error: Binary.readBinMem: decompression failed CallStack (from HasCallStack): error, called at compiler/utils/Binary.hs:192:16 in ghc:Binary make[1]: *** [libraries/dist-haddock/index.html] Error 1 make: *** [all] Error 2

2 5

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.0.1 is available!
by Ben Gamari 21 May '16

21 May '16

KC <kc1956(a)gmail.com> writes: > Hopefully this makes it into the Haskell Platform soon > I believe a Haskell Platform release is imminent, not sure about Stackage. Cheers, - Ben

1 0

HEAD failing
by Simon Peyton Jones 19 May '16

19 May '16

Devs, I’m getting this on a clean build of HEAD on Linux Unexpected failures: /tmp/ghctest/0MzM7D/1/2/3/./rts/T11108 T11108 [bad stdout] (normal) /tmp/ghctest/0MzM7D/1/2/3/./rts/T8308/T8308 T8308 [bad stdout] (normal) Two things · would it be possible to remove the long /tmp/blah prefix? · What’s wrong with these two rts tests? I see that #11108 already reports the failure, and I’ve re-opened #8308 Simon

2 3

8.0.1 source tarballs available (yet again)
by Ben Gamari 18 May '16

18 May '16

tl;dr: We are giving this release another attempt. Cross your fingers and try building again. Hello GHC packagers, Thanks for your help in the last few days working through what were hopefully the last issues in the release. I've uploaded a new set of source tarballs at, http://downloads.haskell.org/~ghc/8.0.1/ These tarballs are derived from, 787900138b94790ddd13d76c2853d789d3335a5d This commit differs from the previous tarball in a number of ways, * a variety of packaging issues surrounding haddock's documentation have been fixed * the ghc-boot library has been split up. It was pointed out quite late that the previous structure of ghc-boot greatly increased the dependency footprint of the template-haskell package, which would have made it nearly impossible to upgrade the bytestring and binary packages. * a pair of fixes for crashes on PowerPC have been merged * a patch addressing a serious performance issue in parallel garbage collection has been merged * the bytestring module has been bumped to 0.8.10.1, fixing a rather serious correctness issue on big-endian systems We'll have the usual one-week build window for binary distributions. As always, let either Austin or I know if you have any trouble building your distribution. I have yet to push the ghc-8.0.1 tag in case we encounter unexpected issues but all of my builds with this tarball thusfar have gone quite well (then again, so did those of the previous tarball). Good luck and thanks for all of your work! Cheers, - Ben

6 13

Re: [GHC] #11140: add command-line option to GHC to dump raw parse trees of Haskell programs
by Alan & Kim Zimmerman 18 May '16

18 May '16

I'm with mpickering on this one. Each stage has a debug format that makes sense for the stage. For parsing it is the exact ast Alan On 18 May 2016 12:43 PM, "GHC" <ghc-devs(a)haskell.org> wrote: > #11140: add command-line option to GHC to dump raw parse trees of Haskell > programs > -------------------------------------+------------------------------------- > Reporter: bollu | Owner: > Type: feature request | Status: new > Priority: low | Milestone: > Component: Compiler | Version: 7.10.2 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > > Comment (by mpickering): > > That is true but by them stages in the compilation pipeline you don't care > about what the raw format looks like. When modifying the parser you need > to know the precise structure of the AST rather than some pretty printed > version produced by `Outputtable`. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11140#comment:6> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0