Re: A type checker plugin for row types
Here are my stabs at answers to two of your questions. > • When/where exactly do Derived constraints arise? I'm not recognizing them > in the OutsideIn paper. I agree with others' comments on this point, but perhaps I can expand. A Derived constraint is essentially a Wanted constraint, but one where there is no need for evidence. They arise for several reasons: - If we have Ord a as a Wanted, then we'll get Eq a (a superclass constraint) as a Derived. While GHC has no need for an Eq a dictionary, perhaps solving the Eq a constraint will help us solve the Ord a constraint. So the Eq a is Derived. - Functional dependencies and type family dependencies give rise to Derived constraints. That is, if we have class C a b | a -> b, instance C Int Bool, and [W] C Int a, then we'll get [D] a ~ Bool. - GHC says that Wanteds cannot rewrite Wanteds. That is, if we have [W] a ~ Bool and [W] a ~ Int, we *don't* want GHC to simplify to [W] Int ~ Bool and then report that. It's very confusing to users! However, sometimes, (I don't have an example) we need Wanteds to rewrite Wanteds in order to make progress. So GHC clones Wanteds into Deriveds, and says that Deriveds *can* rewrite Deriveds. Perhaps after a lot of rewriting, some variables will unify, and then GHC can make progress on the Wanteds. Of course, all this cloning would be non-performant, so GHC essentially does a copy-on-write implementation, where many constraints are [WD], both Wanted and Derived. While Deriveds *arise* for several reasons, they contribute back to the world in only one: unification. That is, the whole point of Deriveds is so that GHC will discover [D] a ~ Int and then set a := Int. > • GHC has various kinds of variable and skolem (e.g. signature skolem) that > I'm not recognizing in the OutsideIn paper. Is there a comprehensive > discussion of them all? I'm unaware of one, but here are some pointers. - A skolem tends to be a user-written type variable, unifiable with no other. If you have a declaration (id :: a -> b; id x = x), GHC will reject because it won't unify a with b. a and b are skolems. - GHC also has "super-skolems", which have a slightly different behavior w.r.t. instances. See Note [Binding when looking up instances] in InstEnv. I've never had to care about this distinction. - GHC has several different types of unification variables (= metavars). * A TauTv is your regular, run-of-the-mill unification variable. It can unify only with monotypes. * A SigTv is a metavar that can unify only with another variable. See Note [Signature skolems] in TcType for examples of why this is useful. (Editorial comment: I think the design around SigTvs is wrong, because generally there is a set of variables a given SigTv should not unify with. But GHC doesn't track this info.) * FlatMetaTvs and FlatSkolTvs are an implementation detail of how GHC deals with type families. They are documented in Note [The flattening story] in TcFlatten. I think that's it, but feel free to ask if you run into more. (In case you're wondering, I didn't really look over the design you're proposing. I leave that to others.) Good luck! Richard > On Sep 11, 2017, at 9:48 AM, Ben Gamari wrote: > > On September 11, 2017 9:34:15 AM GMT+01:00, Adam Gundry > wrote: >> Hi Nick, >> >> This is great work, and I look forward to seeing the code once it is >> ready. I've had a quick glance over your wiki page, and thought I >> should >> send you some initial comments, though it deserves deeper attention >> which I will try to find time to give it. :-) >> >> I don't see a reference to Iavor's paper "Improving Haskell Types with >> SMT" (http://yav.github.io/publications/improving-smt-types.pdf). If >> you've not come across it, it might give a useful alternative >> perspective on how plugins work, especially with regard to derived >> constraints. >> >> The following is based on my faulty memory, so apologies if it is out >> of >> date or misleading... >> >>> When/where exactly do Derived constraints arise? >> >> Suppose I have a class with an equality superclass >> >> class a ~ b => C a b >> >> and a wanted constraint `C alpha Int`, for some touchable variable >> `alpha`. This leads to a derived constraint `alpha ~ Int` thanks to the >> superclass (derived means we don't actually need evidence for it in >> order to build the core term, but solving it might help fill in some >> touchable variables). Sorry if this is obvious and not exact enough! >> >>> When do touchables "naturally" arise in Given constraints? >> >> Do you mean "touchable" or "unification variable" here (and >> elsewhere?). >> A skolem is always untouchable, but the converse is not true. >> >> I think that unification variables can arise in Given constraints, but >> that they will always be untouchable. Suppose we have defined >> >> f :: forall a b . ((a ~ b) => a -> b) -> Int >> >> (never mind that it is ambiguous) and consider type-checking the
Re: Phab: conditional approval
William Casarin recently tweeted a link to the bitcoincore devs ACK system[1], which are Concept ACK - Agree with the idea and overall direction, but haven't reviewed the code changes or tested them. utACK (untested ACK) - Reviewed and agree with the code changes but haven't actually tested them. Tested ACK - Reviewed the code changes and have verified the functionality or bug fix. ACK - A loose ACK can be confusing. It's best to avoid them unless it's a documentation/comment only change in which case there is nothing to test/verify; therefore the tested/untested distinction is not there. NACK - Disagree with the code changes/concept. Should be accompanied by an explanation. [1] https://github.com/bitcoin/bitcoin/issues/6100 Alan On 14 September 2017 at 18:37, Richard Eisenberg wrote: > Yes, this works for me. > > As for merging, I'm always very grateful when Ben does it -- though I > agree that it would make more sense for me to do it when I can > test-then-merge. > > Thanks, > Richard > > > > On Sep 13, 2017, at 10:29 AM, Ben Gamari wrote: > > > > Simon Marlow writes: > > > >> On 19 August 2017 at 03:56, Richard Eisenberg > wrote: > >> > >>> Hi devs, > >>> > >>> When reviewing a diff on Phab, I can "accept" or "request changes". > >>> Sometimes, though, I want to do both: I suggest very minor (e.g., typo) > >>> changes, but then when these changes are made, I accept. I'm leery of > >>> making the suggestions and saying "accept", because then someone > working > >>> quickly may merge without noticing the typos. Does Phab have such an > option? > >>> > >> > >> "Accept with nits" is standard practice, but you're right it can go > wrong > >> when someone else is merging accepted diffs. We could adopt a standard > >> comment keyword, e.g. "NITS" that indicates you'd like the nits to be > fixed > >> before committing, perhaps? > >> > > Sounds reasonable to me. > > > > > >> Also, I don't think it's a good idea to merge commits when the author > is a > >> committer, they can land themselves. > >> > > I would be quite happy to not have to merge such patches; I merely merge > > them currently since I thought it was generally expected. > > > > On the other hand, I generally do integration builds on the batches of > > patches that I merge which can sometimes catch validation issues. > > However, I expect this will be less of an issue with the > > test-before-merge support in the pipeline. > > > > Cheers, > > > > - Ben > > > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Phab: conditional approval
Yes, this works for me. As for merging, I'm always very grateful when Ben does it -- though I agree that it would make more sense for me to do it when I can test-then-merge. Thanks, Richard > On Sep 13, 2017, at 10:29 AM, Ben Gamari wrote: > > Simon Marlow writes: > >> On 19 August 2017 at 03:56, Richard Eisenberg wrote: >> >>> Hi devs, >>> >>> When reviewing a diff on Phab, I can "accept" or "request changes". >>> Sometimes, though, I want to do both: I suggest very minor (e.g., typo) >>> changes, but then when these changes are made, I accept. I'm leery of >>> making the suggestions and saying "accept", because then someone working >>> quickly may merge without noticing the typos. Does Phab have such an option? >>> >> >> "Accept with nits" is standard practice, but you're right it can go wrong >> when someone else is merging accepted diffs. We could adopt a standard >> comment keyword, e.g. "NITS" that indicates you'd like the nits to be fixed >> before committing, perhaps? >> > Sounds reasonable to me. > > >> Also, I don't think it's a good idea to merge commits when the author is a >> committer, they can land themselves. >> > I would be quite happy to not have to merge such patches; I merely merge > them currently since I thought it was generally expected. > > On the other hand, I generally do integration builds on the batches of > patches that I merge which can sometimes catch validation issues. > However, I expect this will be less of an issue with the > test-before-merge support in the pipeline. > > Cheers, > > - Ben > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Perf improvement
Bump it down, maybe... it got /better/! | -Original Message- | From: Ben Gamari [mailto:b...@smart-cactus.org] | Sent: 14 September 2017 16:54 | To: Simon Peyton Jones ; ghc-devs@haskell.org | Subject: Re: Perf improvement | | Simon Peyton Jones via ghc-devs writes: | | > I'm seeing this in validate | > | > bytes allocated value is too low: | > | > (If this is because you have improved GHC, please | > | > update the test so that GHC doesn't regress again) | > | > ExpectedT5837(normal) bytes allocated: 56782344 +/-7% | > | > Lower bound T5837(normal) bytes allocated: 52807579 | > | > Upper bound T5837(normal) bytes allocated: 60757109 | > | > Actual T5837(normal) bytes allocated: 52424864 | > | > Deviation T5837(normal) bytes allocated: -7.7 % | > | > *** unexpected stat test failure for T5837(normal) Does anyone else? | | Unfortunately I'm not seeing this locally. It sounds like yet another | environmentally-sensitive issue. Perhaps we should just bump it. | | Cheers, | | - Ben ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: ./validate --slow results
Simon Peyton Jones via ghc-devs writes: > Wow... 97 unexpected failures is bad. > > Ben/David/someone else: might you investigate/characterise them? > I periodically run --slow and have opened a number of tickets in response in the past (#11819 being the one I was able to easily find). Bartosz, perhaps you could add a comment to that ticket with your results? David, do you think you could take a few hours to go through the failing tests and classify them thematically? Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Perf improvement
Simon Peyton Jones via ghc-devs writes: > I'm seeing this in validate > > bytes allocated value is too low: > > (If this is because you have improved GHC, please > > update the test so that GHC doesn't regress again) > > ExpectedT5837(normal) bytes allocated: 56782344 +/-7% > > Lower bound T5837(normal) bytes allocated: 52807579 > > Upper bound T5837(normal) bytes allocated: 60757109 > > Actual T5837(normal) bytes allocated: 52424864 > > Deviation T5837(normal) bytes allocated: -7.7 % > > *** unexpected stat test failure for T5837(normal) > Does anyone else? Unfortunately I'm not seeing this locally. It sounds like yet another environmentally-sensitive issue. Perhaps we should just bump it. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Perf improvement
Simon Peyton Jones via ghc-devs writes: > I'm seeing this in validate > > bytes allocated value is too low: > > (If this is because you have improved GHC, please > > update the test so that GHC doesn't regress again) > > ExpectedT5837(normal) bytes allocated: 56782344 +/-7% > > Lower bound T5837(normal) bytes allocated: 52807579 > > Upper bound T5837(normal) bytes allocated: 60757109 > > Actual T5837(normal) bytes allocated: 52424864 > > Deviation T5837(normal) bytes allocated: -7.7 % > > *** unexpected stat test failure for T5837(normal) This test has historically been quite unstable. I'm running a validate as we speak; I'll let you know if I can reproduce this. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: ./validate --slow results
Wow... 97 unexpected failures is bad. Ben/David/someone else: might you investigate/characterise them? Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Bartosz | Nitka | Sent: 14 September 2017 13:57 | To: ghc-devs Devs | Subject: ./validate --slow results | | Hi all, | | I happened to run ./validate --slow on my linux machine and I thought it | would be useful to share the results. | | Results: | | Unexpected results from: | TEST="EtaExpandLevPoly PatternSplice StrictPats T10508_api T11627b | T12809 T12870a T12870b T12870c T12870d T12870e T12870f T12870g T12870h | T12903 T12962 T13366 T13543 T13688 T13780c T13822 T13949 T14137 T2552 | T2783 T3001-2 T4114c T4114d T4188 T4334 T5129 T5363 T5559 T5611 T680 | T7411 T7837 T7944 T8025 T8089 T8542 TH_spliceE5_prof_ext UnsafeReenter | compact_gc compact_share dsrun014 dynamic-paper haddock.Cabal hpc_fork prof- | doc-fib prof-doc-last profinline001 read029 return_mem_to_os | rn041 scc001 scc002 scc003 scc005 space_leak_001 tc165 tryReadMVar2" | | SUMMARY for test run started at Thu Sep 14 04:57:20 2017 PDT | 0:12:27 spent to go through | 6091 total tests, which gave rise to | 24105 test cases, of which | 4531 were skipped | | 143 had missing libraries | 19120 expected passes | 203 expected failures | | 0 caused framework failures | 0 caused framework warnings | 6 unexpected passes |97 unexpected failures | 5 unexpected stat failures | | Unexpected passes: | /tmp/ghctest-e17wqi8b/test | spaces/./dependent/should_compile/dynamic-paper.run dynamic-paper | [unexpected] (optasm) | /tmp/ghctest-e17wqi8b/test | spaces/./indexed-types/should_compile/T7837.run T7837 | [unexpected] (profasm) | /tmp/ghctest-e17wqi8b/test | spaces/./parser/should_compile/read029.run read029 | [unexpected] (optasm) | /tmp/ghctest-e17wqi8b/test | spaces/./rename/should_compile/rn041.run rn041 | [unexpected] (optasm) | /tmp/ghctest-e17wqi8b/test | spaces/./simplCore/should_fail/T7411.run T7411 | [unexpected] (hpc) | /tmp/ghctest-e17wqi8b/test | spaces/./typecheck/should_compile/tc165.run tc165 | [unexpected] (optasm) | | Unexpected failures: | /tmp/ghctest-e17wqi8b/test spaces/./codeGen/should_run/T5129.run | T5129 [bad exit code] (hpc) | /tmp/ghctest-e17wqi8b/test spaces/./codeGen/should_run/T5129.run | T5129 [bad exit code] (optasm) | /tmp/ghctest-e17wqi8b/test spaces/./codeGen/should_run/T5129.run | T5129 [bad exit code] (threaded2) | /tmp/ghctest-e17wqi8b/test spaces/./codeGen/should_run/T5129.run | T5129 [bad exit code] (dyn) | /tmp/ghctest-e17wqi8b/test | spaces/./concurrent/should_run/T5611.runT5611 [bad | stdout] (ghci) | /tmp/ghctest-e17wqi8b/test | spaces/./concurrent/should_run/tryReadMVar2.run | tryReadMVar2 [bad heap profile] (profasm) | /tmp/ghctest-e17wqi8b/test | spaces/./deSugar/should_run/dsrun014.rundsrun014 | [bad stderr] (hpc) | /tmp/ghctest-e17wqi8b/test | spaces/./deSugar/should_run/dsrun014.rundsrun014 | [bad stderr] (optasm) | /tmp/ghctest-e17wqi8b/test | spaces/./deSugar/should_run/dsrun014.rundsrun014 | [bad stderr] (threaded2) | /tmp/ghctest-e17wqi8b/test | spaces/./deSugar/should_run/dsrun014.rundsrun014 | [bad stderr] (dyn) | /tmp/ghctest-e17wqi8b/test | spaces/./dependent/should_fail/T13780c.run T13780c | [stderr mismatch] (normal) | /tmp/ghctest-e17wqi8b/test | spaces/./dependent/should_compile/dynamic-paper.run | dynamic-paper [exit code non-0] (profasm) | /tmp/ghctest-e17wqi8b/test spaces/./driver/T4114d.run | T4114d [bad exit code] (ghci) | /tmp/ghctest-e17wqi8b/test spaces/./driver/T4114c.run | T4114c [bad exit code] (ghci) | /tmp/ghctest-e17wqi8b/test spaces/./ghc-api/T10508_api.run | T10508_api [bad exit code] (profasm) | /tmp/ghctest-e17wqi8b/test | spaces/./numeric/should_compile/T8542.run T8542 | [stderr mismatch] (hpc) | /tmp/ghctest-e17wqi8b/test spaces/./ghc-api/T10508_api.run | T10508_api [bad exit code] (profthreaded) | /tmp/ghctest-e17wqi8b/test | spaces/./partial-sigs/should_compile/PatternSplice.run | PatternSplice [exit code non-0] (profasm) | /tmp/ghctest-e17wqi8b/test spaces/./patsyn/should_run/T13688.run | T13688 [exit code non-0] (profasm) | /tmp/ghctest-e17wqi8b/test spaces/./patsyn/should_run/T13688.run | T13688 [exit code non-0] (profthreaded) | /tmp/ghctest-e17wqi8b/test | spaces/./profiling/should_run/T3001-2.run
./validate --slow results
Hi all, I happened to run ./validate --slow on my linux machine and I thought it would be useful to share the results. Results: Unexpected results from: TEST="EtaExpandLevPoly PatternSplice StrictPats T10508_api T11627b T12809 T12870a T12870b T12870c T12870d T12870e T12870f T12870g T12870h T12903 T12962 T13366 T13543 T13688 T13780c T13822 T13949 T14137 T2552 T2783 T3001-2 T4114c T4114d T4188 T4334 T5129 T5363 T5559 T5611 T680 T7411 T7837 T7944 T8025 T8089 T8542 TH_spliceE5_prof_ext UnsafeReenter compact_gc compact_share dsrun014 dynamic-paper haddock.Cabal hpc_fork prof-doc-fib prof-doc-last profinline001 read029 return_mem_to_os rn041 scc001 scc002 scc003 scc005 space_leak_001 tc165 tryReadMVar2" SUMMARY for test run started at Thu Sep 14 04:57:20 2017 PDT 0:12:27 spent to go through 6091 total tests, which gave rise to 24105 test cases, of which 4531 were skipped 143 had missing libraries 19120 expected passes 203 expected failures 0 caused framework failures 0 caused framework warnings 6 unexpected passes 97 unexpected failures 5 unexpected stat failures Unexpected passes: /tmp/ghctest-e17wqi8b/test spaces/./dependent/should_compile/dynamic-paper.run dynamic-paper [unexpected] (optasm) /tmp/ghctest-e17wqi8b/test spaces/./indexed-types/should_compile/T7837.run T7837 [unexpected] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./parser/should_compile/read029.run read029 [unexpected] (optasm) /tmp/ghctest-e17wqi8b/test spaces/./rename/should_compile/rn041.run rn041 [unexpected] (optasm) /tmp/ghctest-e17wqi8b/test spaces/./simplCore/should_fail/T7411.run T7411 [unexpected] (hpc) /tmp/ghctest-e17wqi8b/test spaces/./typecheck/should_compile/tc165.run tc165 [unexpected] (optasm) Unexpected failures: /tmp/ghctest-e17wqi8b/test spaces/./codeGen/should_run/T5129.run T5129 [bad exit code] (hpc) /tmp/ghctest-e17wqi8b/test spaces/./codeGen/should_run/T5129.run T5129 [bad exit code] (optasm) /tmp/ghctest-e17wqi8b/test spaces/./codeGen/should_run/T5129.run T5129 [bad exit code] (threaded2) /tmp/ghctest-e17wqi8b/test spaces/./codeGen/should_run/T5129.run T5129 [bad exit code] (dyn) /tmp/ghctest-e17wqi8b/test spaces/./concurrent/should_run/T5611.runT5611 [bad stdout] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./concurrent/should_run/tryReadMVar2.run tryReadMVar2 [bad heap profile] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./deSugar/should_run/dsrun014.rundsrun014 [bad stderr] (hpc) /tmp/ghctest-e17wqi8b/test spaces/./deSugar/should_run/dsrun014.rundsrun014 [bad stderr] (optasm) /tmp/ghctest-e17wqi8b/test spaces/./deSugar/should_run/dsrun014.rundsrun014 [bad stderr] (threaded2) /tmp/ghctest-e17wqi8b/test spaces/./deSugar/should_run/dsrun014.rundsrun014 [bad stderr] (dyn) /tmp/ghctest-e17wqi8b/test spaces/./dependent/should_fail/T13780c.run T13780c [stderr mismatch] (normal) /tmp/ghctest-e17wqi8b/test spaces/./dependent/should_compile/dynamic-paper.run dynamic-paper [exit code non-0] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./driver/T4114d.run T4114d [bad exit code] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./driver/T4114c.run T4114c [bad exit code] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./ghc-api/T10508_api.run T10508_api [bad exit code] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./numeric/should_compile/T8542.run T8542 [stderr mismatch] (hpc) /tmp/ghctest-e17wqi8b/test spaces/./ghc-api/T10508_api.run T10508_api [bad exit code] (profthreaded) /tmp/ghctest-e17wqi8b/test spaces/./partial-sigs/should_compile/PatternSplice.run PatternSplice [exit code non-0] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./patsyn/should_run/T13688.run T13688 [exit code non-0] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./patsyn/should_run/T13688.run T13688 [exit code non-0] (profthreaded) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T3001-2.run T3001-2 [exit code non-0] (prof_hb) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/scc003.runscc003 [bad profile] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T11627b.run T11627b [bad heap profile] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T12962.runT12962 [bad profile] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/scc003.runscc003 [bad profile] (profthreaded) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T12962.runT12962 [b
Perf improvement
I'm seeing this in validate bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) ExpectedT5837(normal) bytes allocated: 56782344 +/-7% Lower bound T5837(normal) bytes allocated: 52807579 Upper bound T5837(normal) bytes allocated: 60757109 Actual T5837(normal) bytes allocated: 52424864 Deviation T5837(normal) bytes allocated: -7.7 % *** unexpected stat test failure for T5837(normal) Does anyone else? Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs