- ghc-devs - Haskell.org

Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms
by Shayan Najd 25 Oct '18

25 Oct '18

Dear GHC hackers, On our work on the new front-end AST for GHC [0] based on TTG [1], we would like to use a pattern synonym like the following [2]: {{{ pattern LL :: HasSrcSpan a => SrcSpan -> SrcSpanLess a -> a pattern LL s m <- (decomposeSrcSpan -> (m , s)) where LL s m = composeSrcSpan (m , s) }}} We know that any match on `LL` patterns, makes the pattern matching total, as it uses a view pattern with a total output pattern (i.e., in `decomposeSrcSpan -> (m , s)`, the pattern `(m , s)` is total). As far as I understand, currently COMPLETE pragmas cannot be used with such a polymorphic pattern. What do you suggest us to do to avoid the false incomplete pattern matching warnings? Thanks, Shayan [0] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow [1] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGr… [2] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/HandlingSou…

2 1

Shall we make -dsuppress-uniques default?
by Ömer Sinan Ağacan 24 Oct '18

24 Oct '18

I asked this on IRC and didn't hear a lot of opposition, so as the next step I'd like to ask ghc-devs. I literally never need the details on uniques that we currently print by default. I either don't care about variables too much (when not comparing the output with some other output), or I need -dsuppress-uniques (when comparing outputs). The problem is I have to remember to add -dsuppress-uniques if I'm going to compare the outputs, and if I decide to compare outputs after the fact I need to re-generate them with -dsuppress-uniques. This takes time and effort. If you're also of the same opinion I suggest making -dsuppress-uniques default, and providing a -dno-suppress-uniques (if it doesn't already exist). Ömer

4 4

Why align all pinned array payloads on 16 bytes?
by Ömer Sinan Ağacan 24 Oct '18

24 Oct '18

Hi, I just found out we currently align all pinned array payloads to 16 bytes and I'm wondering why. I don't see any comments/notes on this, and it's also not part of the primop documentation. We also have another primop for aligned allocation: newAlignedPinnedByteArray#. Given that alignment behavior of newPinnedByteArray# is not documented and we have another one for aligned allocation, perhaps we can remove alignment in newPinnedByteArray#. Does anyone remember what was the motivation for always aligning pinned arrays? Thanks Ömer

5 6

Hadrian has been merged!
by Ben Gamari 23 Oct '18

23 Oct '18

Hi everyone, Hadrian is now merged into the GHC tree. For better or worse, due to the large number of merge commits in the Hadrian repository we were unable to squash the early history of the project. If you encounter trouble using the Hadrian build system please file a ticket on Trac, setting the "Component" field to "Build System (Hadrian)". I have renamed the old "Build System" component in Trac's issue tracker to "Build System (make)" to avoid confusion. Hadrian tickets opened before the merge will remain on GitHub. Likewise, if you would like to contribute to Hadrian please do so via Phabricator. The remaining pull requests against the GitHub repository will be merged in due course but further requests will be redirected to Phabricator. Cheers, - Ben

1 0

[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