- ghc-devs - Haskell.org

GHC's module hierarchy
by Simon Peyton Jones 02 Oct '19

02 Oct '19

Dear ghc-devs hsyl20 proposes a radical overhaul of the module structure of GHC itself. He or she suggested it six months ago in https://ghc.haskell.org/trac/ghc/ticket/13009 and has now offered a monster patch https://phabricator.haskell.org/D3647 It's clearly the result of a lot of work, but I was the only one who responded on the original ticket, and it'll affect all of your lives in a very immediate way. So, would you like to * consider the idea * look at the actual re-mapping of modules hsyl20 proposals * express an opinion about whether to go ahead Probably the ticket, rather than Phab, is the best place to comment on the general idea. I'd like to thank hsyl20. GHC's rather flat module structure has grown incrementally over years. But still, there are pros and cons. Simon

2 1

How does the ambiguity check work
by Jan van Brügge 30 Sep '19

30 Sep '19

Hi lovely people, I am currently trying to wrap my head around the ambiguity check in GHC. In particular for those two instances: ``` class RowEquality where rowEqual :: Bool instance (1 ~ 2) => RowEquality where rowEqual = True instance ( ("foo" ::: Int & RNil) ~ ("bar" ::: String & "foo" ::: Int & RNil) ) => RowEquality where rowEqual = True ``` I would expect them to behave the same but the second one throws an error when trying to compile the module (*before* using `rowEqual` - that would obviously throw a type error in both cases): ``` Test.hs:24:10: error: • Could not deduce: (| "foo" :: Int |) ~ (| "bar" :: [Char], "foo" :: Int |) from the context: (("foo" ::: Int) & RNil) ~ (("bar" ::: String) & (("foo" ::: Int) & RNil)) bound by an instance declaration: ((("foo" ::: Int) & RNil) ~ (("bar" ::: String) & (("foo" ::: Int) & RNil))) => RowEquality at Test.hs:24:10-94 • In the ambiguity check for an instance declaration To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the instance declaration for 'RowEquality ``` I have troubles to understand why GHC tries to solve the constraint there. I worked through `checkAmbiguity` in `TcValidity` and the function it calls, but from what I can see is that it also tries to solve the `(1 ~ 2)` and fails in the same way as with the second one. I cannot find any reason why the two are treated differently. Thank you Jan

3 2

fragile tests
by Richard Eisenberg 26 Sep '19

26 Sep '19

Hi devs, I believe threadstatus-9333 is more fragile than it's listed as. See https://gitlab.haskell.org/rae/ghc/-/jobs/163182 <https://gitlab.haskell.org/rae/ghc/-/jobs/163182>, where I haven't been anywhere near this area of the code... Also, on a separate test, I found that compact_gc got killed. See https://gitlab.haskell.org/rae/ghc/-/jobs/163526 <https://gitlab.haskell.org/rae/ghc/-/jobs/163526>. Should these be fragile? Thanks, Richard

2 1

Tracking Progress of #7353 (New Windows IO Manager)
by Travis Whitaker 24 Sep '19

24 Sep '19

Hello Haskell friends, Even though I no longer work at a Windows shop, I've been watching https://gitlab.haskell.org/ghc/ghc/issues/7353 with great interest. Last I knew Tamar Christina was heroically hacking away on a new IO manager for Windows. Although my low-level Windows knowledge is likely insufficient for me to contribute significantly, I'd be very interested in testing the new IO manager and helping with debugging in any way I can. How might one go about building a GHC with this new Windows IO manager? Thanks, as always, for all your hard work, Travis Whitaker

2 1

What does a milestone mean?
by Matthew Pickering 24 Sep '19

24 Sep '19

Hi, It seems that basically every new issues gets triaged with the 8.10.1 milestone, what does this mean? It seems like a lot of the issue's won't get fixed for 8.10, or at any foreseeable point in the future which dilutes the milestoning. Therefore I don't think we should assign a certain milestone to a ticket unless either 1. The issue is considered necessary to fix for that milestone (ie, a regression) 2. Someone is planning to work on the ticket for that milestone (ie, a feature/improvement) Then the milestone actually has some meaning. Cheers, Matt

2 1

Filtering GitLab mentions
by Ben Gamari 24 Sep '19

24 Sep '19

Hi everyone, During a discussion on procedural matters earlier today it was (yet again) noted that GitLab notification emails are quite chatty and consequently it is easy to lose the signal in the noise. However, during this discussion we also realized that much of the issue can be mitigated with a simple email filter to identify explicit @-mentions. I find that: from:gitlab.haskell.org and @bgamari and header:X-GitLab-Discussion-Id isolates emails arising from @-mentions fairly effetively. If your MUA doesn't support filtering by arbitrary headers you can replace the "header" predicate with simply a mention of the word "commented". If you are active on GitLab I would encourage you to setup such a filter; I was surprised by how many comments I had overlooked. Cheers, - Ben

1 0

GHC 8.10.1 Release Plan
by Ben Gamari 23 Sep '19

23 Sep '19

tl;dr. If you have unmerged work that you would like to be in GHC 8.10 please reply to this email and submit it for review in the next couple of weeks. Hello everyone, Now that GHC 8.8.1 is behind us it is time that we begin thinking about 8.10. There seems to be broad consensus within the subset of the community that I sampled that we should try to hold to the usual release date near the end of year for 8.10.1. I believe that this is a feasible goal with the caveat that we push the final release back by a couple of weeks in recognition that busy schedules of the holiday season tends to throw unexpected wrenches into the release process. In particular I would suggest the following concrete schedule: October 18 2019: start of one week freeze in preparation for branching October 25 2019: ghc-8.10 branch cut November 8 2019: 8.10.1-alpha1 November 22 2019: 8.10.1-alpha2 December 6 2019: 8.10.1-alpha3 December 20 2019: 8.10.1-rc1 January 10 2020: Final 8.10.1 release If you have yet-unmerged work that you would like to see in GHC 8.10 please do be in touch and open a merge request ASAP. One obvious question is how we will avoid the many delays that plagued the 8.8.1 release. Without delving too deep into the specific reasons for these delays, the reasons fell into two buckets: 1. delays due to CI stabilization 2. coordination delays with upstream libraries 3. fallout from MonadFail changes which landed only late in the release cycle Of these, (1) is largely behind us and (3) will be avoided by ensuring that core libraries changes are landed *before* the branch date. This leaves consideration (2). The problem of upstream library coordination has always been a tricky one but has grown more acute as our release schedule has accelerated. While no technical solution will eliminate the issue entirely, we believe that decoupling GHC's release schedule from those of its dependencies' is an important mitigation. We will be discussing this with upstream library maintainers in the coming weeks to establish how we can ensure that releases are available well ahead of the GHC 8.10 release, ideally by alpha2. Cheers, - Ben

7 7

Test cases and missing RTS linker
by Stefan Schulze Frielinghaus 18 Sep '19

18 Sep '19

Hi all, How is a test case supposed to be marked if it makes use of the RTS linker which itself is not supported on some architectures? For example, some test cases are marked for a particular architecutre like PowerPC64 that it fails because of a missing RTS linker. Style (A) test('T10052', [when(arch('powerpc64') or arch('powerpc64le'), expect_broken(11259)), req_interp], makefile_test, ['T10052']) Whereas another test case is marked to be skipped if RTS linker is missing. Style (B) test('static-plugins', [extra_files(['simple-plugin/']), unless(config.have_RTS_linker, skip), expect_broken_for(16803, prof_ways), extra_run_opts('"' + config.libdir + '"')], compile_and_run, ['-package ghc -isimple-plugin/']) If style (A) is the way to go, then for every architecture which does not support the RTS linker a when-clause must be added. If style (B) is the way to go, then shouldn't we change all test cases of style (A) to style (B)? Personally I prefer style (B) over (A) because it makes it easier to add an architecture where the RTS linker is not provided. Even if the RTS linker is provided after some time, then the test case must not be changed. Once PowerPC64 supports the RTS linker all when-clauses must be removed. Any thoughts which style to use? Cheers, Stefan

1 0

validate-whitespace
by Alejandro Serrano Mena 18 Sep '19

18 Sep '19

Hi GHC devs, I have made a rebase to bring my merge request [ https://gitlab.haskell.org/ghc/ghc/merge_requests/1659] up to date with the current GHC codebase. In the process there were some conflicts (as expected) which I could solve. However, now that I have pushed the result, I get these messages from the CI infrastructure: $ validate-whitespace .git $(git rev-list $base..$CI_COMMIT_SHA) ===================================================================================== commit 0d92f8c898ccbf2ffb602bc75e50e9ffd44811d8 has whitespace linter issues: *ERROR* compiler/typecheck/TcUnify.hs:810: introduces trailing whitespace > " " *ERROR* compiler/typecheck/TcUnify.hs:818: introduces trailing whitespace > " = " Validation FAILED for 0d92f8c898ccbf2ffb602bc75e50e9ffd44811d8 ===================================================================================== commit 465d27f2119d7bdbe06832dd79c3848e27b4aaef has whitespace linter issues: *ERROR* compiler/typecheck/TcExpr.hs:1315: introduces trailing whitespace > " ; subst <- if xopt LangExt.ImpredicativeTypes dflags " *ERROR* compiler/typecheck/TcExpr.hs:1472: introduces trailing whitespace > " _ -> return emptyTCvSubst " *ERROR* compiler/typecheck/TcExpr.hs:1513: introduces trailing whitespace > " " Validation FAILED for 465d27f2119d7bdbe06832dd79c3848e27b4aaef ===================================================================================== Validation FAILED because at least one commit had linter errors! What is the right approach to fix these problems? I can fix the whitespace issues in a new commit, but I don't see how to fix them in all the interim commits :( Thanks in advance and kind regards, Alejandro

2 1

Fwd: Why do Constraint Tuple data constructors exist?
by Joe Crayne 17 Sep '19

17 Sep '19

My question arrised in the following context: ``` module ForEachHelper where import Data.Kind import GHC.TypeLits type family ForEach (c :: k -> Constraint) (xs :: [k]) :: Constraint where ForEach c '[] = () ForEach c (x:xs) = (c x, ForEach c xs) type family Replicate n x where Replicate 0 x = '[] Replicate n x = x : Replicate (n-1) x data ForEachHelper n c x where ForEachHelper :: ForEach c (Replicate n x) => ForEachHelper n c x -- The following solve function was actually in another module from the definitions above: solve :: ( KnownNat n, c x -- Solved via plugin: -- , ForEach c (Replicate n x) ) => p c -> q x -> ForEachHelper n c x solve pc px = ForEachHelper ``` I was trying to write a plugin that could solve the (ForEach c (Replicate n x)) constraint. I need an EvTerm that this constraint. The first thing I tried was to use the given EvTerm for the (c x) constraint without change. This causes the program to compile but ultimately and, perhaps not surprisingly, it segfaults when code relies upon the constraint. Then I decided that (ForEach c (Replicate n x)) is a constraint tuple and the proof term should be a tuple constructed using a constraint tuple data constructor. However, this is apparently not possible. When I tried the following code in the initialization of my plugin: cpairCon <- tcLookupDataCon (cTupleDataConName 2) it triggers an error: Can't find interface-file declaration for data constructor GHC.Classes.(%,%) Searching GHC source, I cannot find where or how constraint data constructors are used and notes on commit ffc21506894c7887d3620423aaf86bc6113a1071 were not helpful to me either. Why do constraint tuple data constructor names exist at all if we cannot use them for anything? Is it possible for a plugin to solve the (ForEach c (Replicate n x)) constraint by some other means?

2 1