October 2018 - ghc-devs

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

Phabricator workflow vs. GitHub
by Simon Marlow 07 Oct '18

07 Oct '18

Here's an interesting blog post relevant to previous discussions about Phabricator / GitHub: https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/?fbclid=IwAR3Jy… Yes it's a decidedly pro-Phabricator rant, but it does go into a lot of details about why the Phabricator workflow is productive, and might be useful to those who struggle to get to grips with it coming from GitHub. Cheers Simon

4 6

Please update ghc user's guide for GHC 8.6
by Takenobu Tani 06 Oct '18

06 Oct '18

Dear devs, Would you please update latest document [1] to GHC 8.6 ? [1]: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide Regards, Takenobu

2 2

Does it sound a good idea to implement "backend plugins"?
by Shao, Cheng 05 Oct '18

05 Oct '18

Hi all, I'm thinking of adding "backend plugins" in the current Plugins mechanism which allows one to inspect/modify the IRs post simplifier pass (STG/Cmm), similar to the recently added source plugins for HsSyn IRs. This can be useful for anyone creating a custom GHC backend to target an experimental platform (e.g. the Asterius compiler which targets WebAssembly), and previously in order to retrieve those IRs from the regular pipeline, we need to use Hooks which is somewhat hacky. Does this sound a good idea to you? If so, I can open a trac ticket and a Phab diff for this feature. Best, Shao Cheng

5 6