Re: A type checker plugin for row types

[Richard Eisenberg]

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 

Re: Phab: conditional approval

[Alan & Kim Zimmerman]

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

[Richard Eisenberg]

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

[Simon Peyton Jones via ghc-devs]

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

[Ben Gamari]

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

[Ben Gamari]

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

[Ben Gamari]

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

[Simon Peyton Jones via ghc-devs]

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
|  

Perf improvement

[Simon Peyton Jones via ghc-devs]

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