- ghc-devs - Haskell.org

[ANNOUNCE] GHC 8.6.1 released
by Ben Gamari 22 Oct '18

22 Oct '18

Hello everyone, The GHC team is pleased to announce the availability of GHC 8.6.1, the fourth major release in the GHC 8 series. The source distribution, binary distributions, and documentation for this release are available at https://downloads.haskell.org/~ghc/8.6.1 The 8.6 release fixes over 400 bugs from the 8.4 series and introduces a number of exciting features. These most notably include: * A new deriving mechanism, `deriving via`, providing a convenient way for users to extend Haskell's typeclass deriving mechanism * Quantified constraints, allowing forall quantification in constraint contexts * An early version of the GHCi `:doc` command * The `ghc-heap-view` package, allowing introspection into the structure of GHC's heap * Valid hole fit hints, helping the user to find terms to fill typed holes in their programs * The BlockArguments extension, allowing the `$` operator to be omitted in some unambiguous contexts * An exciting new plugin mechanism, source plugins, allowing plugins to inspect and modify a wide variety of compiler representations. * Improved recompilation checking when plugins are used * Significantly better handling of macOS linker command size limits, avoiding linker errors while linking large projects * The next phase of the MonadFail proposal, enabling -XMonadFailDesugaring by default A full list of the changes in this release can be found in the release notes: https://downloads.haskell.org/~ghc/8.6.1/docs/html/users_guide/8.6.1-notes.… Perhaps of equal importance, GHC 8.6 is the second major release made under GHC's accelerated six-month release schedule and the first set of binary distributions built primarily using our new continuous integration scheme. While the final 8.6 release is around three weeks later than initially scheduled due to late-breaking bug reports, we expect that the 8.8 release schedule shouldn't be affected. Thanks to everyone who has contributed to developing, documenting, and testing this release! As always, let us know if you encounter trouble. How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. 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. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page https://www.haskell.org/ghc/ GHC developers' home page https://ghc.haskell.org/trac/ghc/ Haskell home page https://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: https://ghc.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: https://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: https://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at https://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users https://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 #haskell on IRC, too: https://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: https://www.haskell.org/ghc/reportabug

9 12

Building on windows
by Yotam Ohad 21 Oct '18

21 Oct '18

Hi, I've tried to build ghc on windows 10 with msys. I've installed it with stack as said on the guide. In the msys shell, after updating and installing everything I've tried to run `./configure --enable-tarballs-autodownload` and got the following error: configure: loading site script /mingw64/etc/config.site checking for gfind... no checking for find... /usr/bin/find checking for sort... /usr/bin/sort checking for GHC version date... inferred 8.7.20181017 checking for GHC Git commit id... inferred 46f2906d1c6e1fb732a90882487479a2ebf19ca1 checking for ghc... no configure: error: GHC is required. I have the haskell platform installed (8.4.3), yet it can't find GHC and I'm not sure if I missed something from the guide Yotam

2 3

Help inform GHC's development priorities
by Ben Gamari 18 Oct '18

18 Oct '18

tl;dr. Please a take a minute to express your thoughts on GHC's development priorities via this survey [1]. Hello everyone, The GHC developers want to ensure that we are working on problems that of most importance to you, the Haskell community. To this end we are surveying the community [1], asking how our users interact with GHC and which problems need to be addressed most urgently. We hope you will take a few minutes to give us your thoughts [1]. Thanks in advance for your time and, finally, thanks to the financial supporters that make our work GHC possible. Cheers, - Ben and the rest of the GHC developers [1] https://docs.google.com/forms/d/e/1FAIpQLSdh7sf2MqHoEmjt38r1cxCF-tV76OFCJqU…

1 0

Re: Treatment of unknown pragmas
by Moritz Angermann 17 Oct '18

17 Oct '18

Does this need to be *this* hardcoded? Or could we just parse the pragma and compare it to a list of known pragmas to be parsed from a file (or settings value?). The change in question does: - pragmas = options_pragmas ++ ["cfiles", "contract"] + pragmas = options_pragmas ++ ["cfiles", "contract", "hlint"] to the `compiler/parser/Lexer.x`, and as such is somewhat hardcoded. So we already ignore a bunch of `option_` and those three pragmas. And I see <0,option_prags> { "{-#" { warnThen Opt_WarnUnrecognisedPragmas (text "Unrecognised pragma") (nested_comment lexToken) } } which I believe handles the unrecognisedPragmas case. Can't we have a ignored-pragmas value in the settings, that just lists all those we want to ignore, instead of hardcoding them in the Lexer? That at least feels to me like a less invasive (and easier to adapt) appraoch, that might be less controversial? Yes it's just moving goal posts, but it moves the logic into a runtime value instead of a compile time value. Cheers, Moritz > On Oct 17, 2018, at 4:05 PM, Simon Marlow <marlowsd(a)gmail.com> wrote: > > Simon - GHC provides some protection against mistyped pragma names, in the form of the -Wunrecognised-pragmas warning, but only for {-# ... #-} pragmas. If tools decide to use their own pragma syntax, they don't benefit from this. That's one downside, in addition to the others that Neil mentioned. > > You might say we shouldn't care about mistyped pragma names. If the user accidentally writes {- HLNIT -} and it is silently ignored, that's not our problem. OK, but we cared about it enough for the pragmas that GHC understands to add the special warning, and it's reasonable to expect that HLint users also care about it. > > (personally I have no stance on whether we should have this warning, there are upsides and downsides. But that's where we are now.) > > Cheers > Simon > > On Tue, 16 Oct 2018 at 23:34, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: > I’m still not understanding what’s wrong with > > > > {- HLINT blah blah -} > > > > GHC will ignore it. HLint can look at it. Simple. > > > > I must be missing something obvious. > > > > Simon > > > > From: ghc-devs <ghc-devs-bounces(a)haskell.org> On Behalf Of Simon Marlow > Sent: 16 October 2018 21:44 > To: Neil Mitchell <ndmitchell(a)gmail.com> > Cc: ghc-devs <ghc-devs(a)haskell.org> > Subject: Re: Treatment of unknown pragmas > > > > I suggested to Neil that he add the {-# HLINT #-} pragma to GHC. It seemed like the least worst option taking into account the various issues that have already been described in this thread. I'm OK with adding HLINT; after all we already ignore OPTIONS_HADDOCK, OPTIONS_NHC98, a bunch of other OPTIONS, CFILES (a Hugs relic), and several more that GHC ignores. > > > > We can either > > (a) not protect people from mistyped pragmas, or > > (b) protect people from mistyped pragma names, but then we have to bake in the set of known pragmas > > > > We could choose to have a different convention for pragmas that GHC doesn't know about (as Ben suggests), but then of course we don't get any protection for mistyped pragma names when using that convention. > > > > Cheers > > Simon > > > > > > On Tue, 16 Oct 2018 at 21:12, Neil Mitchell <ndmitchell(a)gmail.com> wrote: > >> A warning flag is an interesting way to deal with the issue. On the >> other hand, it's not great from an ergonomic perspective; afterall, this >> would mean that all users of HLint (and any other tool requiring special > > Yep, this means every HLint user has to do an extra thing. I (the > HLint author) now have a whole pile of "how do I disable warnings in > Stack", and "what's the equivalent of this in Nix". Personally, it ups > the support level significantly that I wouldn't go this route. > > I think it might be a useful feature in general, as new tools could > use the flag to prototype new types of warning, but I imagine once a > feature gets popular it becomes too much fuss. > >>> I think it makes a lot of sense to have a standard way for third-parties >>> to attach string-y information to Haskell source constructs. While it's >>> not strictly speaking necessary to standardize the syntax, doing >>> so minimizes the chance that tools overlap and hopefully reduces >>> the language ecosystem learning curve. >> >> This sounds exactly like the existing ANN pragma, which is what I've wanted LiquidHaskell to move towards for a long time. What is wrong with using the ANN pragma? > > Significant compilation performance penalty and extra recompilation. > ANN pragmas is what HLint currently uses. > >> I'm a bit skeptical of this idea. Afterall, adding cases to the >> lexer for every tool that wants a pragma seems quite unsustainable. > > I don't find this argument that convincing. Given the list already > includes CATCH and DERIVE, the bar can't have been _that_ high to > entry. And yet, the list remains pretty short. My guess is the demand > is pretty low - we're just whitelisting a handful of additional words > that aren't misspellings. > > Thanks, Neil > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

2 1

Goals for GHC 8.8
by Ben Gamari 16 Oct '18

16 Oct '18

Hi everyone, Since GHC 8.6 is almost released it's time to start thinking about our goals for 8.8, which will branch in November. I have added the items that I know are in-flight to the 8.8 status page[1]. If you have a project that you would like to see present in 8.8 then please do add it as well. If you are uncertain of whether you can have a patch up for review by late October then please do speak to me and we can discuss options. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.8.1

5 8

Parser.y rewrite with parser combinators
by Vladislav Zavialov 16 Oct '18

16 Oct '18

Hello devs, Recently I've been working on a couple of parsing-related issues in GHC. I implemented support for the -XStarIsType extension, fixed parsing of the (!) type operator (Trac #15457), allowed using type operators in existential contexts (Trac #15675). Doing these tasks required way more engineering effort than I expected from my prior experience working with parsers due to complexities of GHC's grammar. In the last couple of days, I've been working on Trac #1087 - a 12-year old parsing bug. After trying out a couple of approaches, to my dismay I realised that fixing it properly (including support for bang patterns inside infix constructors, etc) would require a complete rewrite of expression and pattern parsing logic. Worse yet, most of the work would be done outside Parser.y in Haskell code instead, in RdrHsSyn helpers. When I try to keep the logic inside Parser.y, in every design direction I face reduce/reduce conflicts. The reduce/reduce conflicts are the worst. Perhaps it is finally time to admit that Haskell syntax with all of the GHC cannot fit into a LALR grammar? The extent of hacks that we have right now just to make parsing possible is astonishing. For instance, we have dedicated constructors in HsExpr to make parsing patterns possible (EWildPat, EAsPat, EViewPat, ELazyPat). That is, one of the fundamental types (that the type checker operates on) has four additional constructors that exist due to a reduce/reduce conflict between patterns and expressions. I propose a complete rewrite of GHC's parser to use recursive descent parsing with monadic parser combinators. 1. We could significantly simplify parsing logic by doing things in a more direct manner. For instance, instead of parsing patterns as expressions and then post-processing them, we could have separate parsing logic for patterns and expressions. 2. We could fix long-standing parsing bugs like Trac #1087 because recursive descent offers more expressive power than LALR (at the cost of support for left recursion, which is not much of a loss in practice). 3. New extensions to the grammar would require less engineering effort. Of course, this rewrite is a huge chunk of work, so before I start, I would like to know that this work would be accepted if done well. Here's what I want to achieve: * Comparable performance. The new parser could turn out to be faster because it would do less post-processing, but it could be slower because 'happy' does all the sorts of low-level optimisations. I will consider this project a success only if comparable performance is achieved. * Correctness. The new parser should handle 100% of the syntactic constructs that the current parser can handle. * Error messages. The new error messages should be of equal or better quality than existing ones. * Elegance. The new parser should bring simplification to other parts of the compiler (e.g. removal of pattern constructors from HsExpr). And one of the design principles is to represent things by dedicated data structures, in contrast to the current state of affairs where we represent patterns as expressions, data constructor declarations as types (before D5180), etc. Let me know if this is a good/acceptable direction of travel. That's definitely something that I personally would like to see happen. All the best, - Vladislav

10 22

RE: Coordinating the Hadrian merge
by Andrey Mokhov 16 Oct '18

16 Oct '18

Thanks Alp and Ben! I fully agree with you. Let's go ahead. Ben: I guess you'll do the actual merge -- feel free to do this whenever you like. > How should we handle ticket tracking post-merge? The easiest option > would probably be to keep the existing tickets on GitHub and ask that > new tickets be reported via Trac. Yes, this sounds good. Cheers, Andrey -----Original Message----- From: Ben Gamari [mailto:ben@well-typed.com] Sent: 16 October 2018 02:33 To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk>; Alp Mestanogullari <alp(a)well-typed.com> Cc: GHC developers <ghc-devs(a)haskell.org> Subject: RE: Coordinating the Hadrian merge Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> writes: > Hi Ben, > > Yes, I'm fine to merge, but we should make it clear that Hadrian > should not be used just yet: > > 1) It is currently broken due to some recent changes in GHC. > > 2) Alp made tremendous progress with fixing the testsuite failures, but there are still some failures left. > > 3) There are a few usability requests by Simon Marlow that we need to address. > >> In the past we discussed squashing the project's early history >> however I've had very little luck doing this cleanly > Sure, I'm happy to make it clear that things are still in flux and that there are known weaknesses. That being said, I'm not sure it helps to active discourage use. Afterall, there will be little incentive for others to help find and fix the remaining issues unless there are users. > Ouch, it would be a bit grim to merge all those early commits. On the > other hand, I looked at commits at the middle of Hadrian's history and > they look quite sensible, just overly fine-grained. So, even if we > could somehow squash the early history, that probably wouldn't give us > much saving in terms of the commit count -- it would still be more > than 1K. > Right; given that GHC itself has more than 50k commits I'm not terribly concerned about Hadrian's contribution. How should we handle ticket tracking post-merge? The easiest option would probably be to keep the existing tickets on GitHub and ask that new tickets be reported via Trac. Cheers, - Ben

1 0

RE: Coordinating the Hadrian merge
by Andrey Mokhov 16 Oct '18

16 Oct '18

Hi Ben, Yes, I'm fine to merge, but we should make it clear that Hadrian should not be used just yet: 1) It is currently broken due to some recent changes in GHC. 2) Alp made tremendous progress with fixing the testsuite failures, but there are still some failures left. 3) There are a few usability requests by Simon Marlow that we need to address. > In the past we discussed squashing the project's early history > however I've had very little luck doing this cleanly Ouch, it would be a bit grim to merge all those early commits. On the other hand, I looked at commits at the middle of Hadrian's history and they look quite sensible, just overly fine-grained. So, even if we could somehow squash the early history, that probably wouldn't give us much saving in terms of the commit count -- it would still be more than 1K. P.S.: Don't forget to switch off commit notifications when you do the merge ;-) Cheers, Andrey -----Original Message----- From: Ben Gamari [mailto:ben@well-typed.com] Sent: 15 October 2018 23:14 To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk>; Alp Mestanogullari <alp(a)well-typed.com> Cc: GHC developers <ghc-devs(a)haskell.org> Subject: Coordinating the Hadrian merge Hi Andrey and Alp, Before ICFP we concluded that we will merge Hadrian into the GHC tree. This unfortunately took a back-seat priority-wise while I sorted out various release things but I think we are now in a position to make this happen. Andrey, would you be okay with my merging Hadrian as-is into the GHC tree? In the past we discussed squashing the project's early history however I've had very little luck doing this cleanly (primarily due to the difficulty of rebasing in the presence of merge commits) After merging there will be a period where we flush the pull request queue but I don't anticipate this causing much trouble. Cheers, - Ben

3 2

Coordinating the Hadrian merge
by Ben Gamari 15 Oct '18

15 Oct '18

Hi Andrey and Alp, Before ICFP we concluded that we will merge Hadrian into the GHC tree. This unfortunately took a back-seat priority-wise while I sorted out various release things but I think we are now in a position to make this happen. Andrey, would you be okay with my merging Hadrian as-is into the GHC tree? In the past we discussed squashing the project's early history however I've had very little luck doing this cleanly (primarily due to the difficulty of rebasing in the presence of merge commits) After merging there will be a period where we flush the pull request queue but I don't anticipate this causing much trouble. Cheers, - Ben

1 0

Feedback request: GHC performance test-suite
by David Eichmann 10 Oct '18

10 Oct '18

Hello all, I've recently resumed some work started by Jared Weakly on the GHC test suite. This specifically regards performance tests. The work aims to, among some other things, reduce manual work and to log performance test results from our CI server. The proposed change is described in more detail on this wiki page: https://ghc.haskell.org/trac/ghc/wiki/Performance/Tests. I'd appreciate any feedback or questions on this. Thank you and have a great day, David Eichmann -- David Eichmann, Haskell Consultant Well-Typed LLP, http://www.well-typed.com Registered in England & Wales, OC335890 118 Wymering Mansions, Wymering Road, London W9 2NF, England

3 4