- User Since
- Jun 9 2014, 9:34 AM (141 w, 2 d)
Fri, Feb 17
Thu, Feb 16
I have an upcoming patch for this, as I mentioned
Fri, Feb 10
Great -- go for it.
I'm OK with this. Let's add a Note as I suggest above, and land it
Thu, Feb 9
OK well, we probably get better error messages if we report the errors from simplifyDeriv. So I've done that -- see the patch I've put in email to you. Works for all of tests/deriving, except that two error message improve
you should also delete
OK I see.
By all means add the ASSERT (with an explanation). Then good.
Wed, Feb 8
Is there a way to grab the insoluble constraints in approximateWC?
It seems that... works
I'd much prefer to follow comment:7 on Trac Trac #11525. Was there some reason you chose not to do that?
Maybe there are some performance cliffs somewhere. Espcially as I see a similar regression in binary-trees with D3089.
Tue, Feb 7
I'm happy with the approach of starting with a live-var set. Much neater than messing with the guts of the analyser
Mon, Feb 6
That looks right! Thank you!
Sun, Feb 5
Can we land this?
Fri, Feb 3
No, let's NOT put it in the environment. This business of not dropping dead binding applies only at top level, right? If so, it's much clearer just to pass the flag down separately (just one or two levels of functions), as comment:9 suggetss.
I'll consult the steering committee. Meanwhile look at my proposed simplification of the spec, on the ticket.
I'm still totally stuck when it comes to implementing the grand plan involving implication constraints
Let's do (1) or (2). I'm content with (2) as a stop-gap if you want to just commit and open a ticket for refactoring.
Thu, Feb 2
It looks like this was committed despite the performance regressions in perf/compiler/all.T. What's the plan here?
The haddock.base and haddock.Cabal tests regress in allocations by about 20%.
Wouldn't literal strings always float up to the top level eventually? Always discarding ticks on string literals might be the right thing to do.
Wed, Feb 1
Like I say on the ticket, I don't think this is right. You are making the function lazy. But it isn't.
I don't want to delay you but this design has had no serious attention from anyone other than you. And while the patch is small, it commits GHC into the future to implement whatever the change is.
I there s a bug (in bad_tvs), and I wish there had been more debate. The rule seems a bit ad hoc, and once it's in it'll be hard to pull it out.
Motivation? Can we run this through the ghc proposals process?
I'm keen on this patch, but there's an easier way to do it! See comments.
Tue, Jan 31
The reflection library is NOT destroyed by making single-parameter classes into a data type. See https://mail.haskell.org/pipermail/ghc-devs/2017-January/013600.html, under "Third".
Re "major disaster", I'm missing the point. We discussed this before, in the previous version. Suppose we have a newtype axiom:
ntax :: (C a ::: TYPE ConstraintRep) ~R (a :: TYPE LiftedPtrRep)
To avoid being able to extract ContraintRep ~R LiftedPtrRep we decided to weaken one of the coercion constructors, the one that gets a kind coercion from a type coercion. We don't need it, and it's awkward here.
Mon, Jan 30
Thu, Jan 26
But there is a problem: how do we reject types like
Eq a -> a -> a?
Wed, Jan 25
I like your deeplyInstantiate2 much more than tcSplitNestedSigmaTys. Use the former not the latter.
I'm sorry Facundo, I just don't have the bandwidth to dig into this for the next few weeks. Richard, who is in charge of TH, is in a similar bind.
This had a reproducible effect of increasing runtime of fasta by +4.47%. Are runtime effects here expected?
Looks fine to me. I can't see any downsides. Except, I suppose, that
asProxyTypeOf e1 e2
with e2 :: F beta, and F an injective type function. It's just possible that knowing that F beta ~ Proxy gamma might allow the injectivity to kick in, while F beta ~ delta gamma might now.
Tue, Jan 24
Mon, Jan 23
Great moodulo documentation in teh code
I see now. The point is that we want to match up the tau-part of the two types, after discarding any number of enclosing forall or Eq a => wrappings. We might even find a forall to the right of a function arrow (->). So
class C a where op :: a -> forall b. Eq b => b -> b default op :: (Ord a, Eq c) => a -> c -> c
should arguably be OK. (I think you need a Note to explain why it's the Right Thing to ignore all these constraints. You've explained it to Matthew on IRC, so put it in the Note.)
Jan 23 2017
Jan 20 2017
I'm sorry but this patch feels vastly over-weight for what it does. Large slabs of new code, all to deal with a corner case. It just doesn't smell right at all.
Jan 18 2017
I have only worked through about half of this, but it's a start
Jan 17 2017
Here's a minimized version that doesn't depend on any external modules.
Can you give me a small repro case so I can see exactly what you are saying? I can't do it in my head!