I actually have conflicting needs: 1. ghc-typelits-natnormalise, a solver for type-level Nat equations, would benefits from both unflattened givens and unflattened wanteds! Why unflattened givens? because from `[G] 2*x + a ~ 2*x + b` I can derive `a ~ b` Which I could then use to solve: [W] 3*y + a ~ 3*y + b
So for both givens and wanteds I want unflattened constraints, because my simplifier "simplifies" by eliminating equal terms on either side of the '~' I actually had to write my own unflattening function for givens. Now, if flattened wanteds would mean that a single unflattened ` [W] 3*y + a ~ 3*y + b` is split up into multiple flattened wanteds, that could complicate ghc-typelits-natnormalise, although I cannot be sure. So if I could be kept in the loop, and test an API with flattened wanteds early, I could give more feedback on that. 2. ghc-typelits-knownnat, this solves complicated knownnat constraints from simpler ones. e.g. given [G] KnownNat a, [G] KnownNat b, and a [W] KnownNat (a + b), it can create that dictionary using some "magic" dictionary functions. Again, here I benifit from unflattened wanteds because I see [W] KnownNat (a + b), instead of [W] KnownNat fmv 3. ghc-typelits-extra, adds additional operations on types of kind Nat, e.g. LogBase. This one probably benifits from flattened wanteds, so I can solve one "magic" type family at a time. So if I'd had to hazard a guess, I think I'd want to receive my wanteds as an "Either [flattened] [unflattened]" and then return a "Solved (Either [flattened] [unflattened])" as well. On Mon, 2 Mar 2020 at 21:20, Nicolas Frisby <[email protected]> wrote: > If you know of any typechecker plugin authors I've missed, please add them > to the thread. > > In the comments of ticket https://gitlab.haskell.org/ghc/ghc/issues/15147 > several of us agreed that the behavior of the typechecker plugin interface > should change: GHC should no longer unflatten the fmvs in the Wanteds > before passing them to the plugin. > > This is presumably a breaking change to plugins. We might be able to get > by with some sort of flag indicating if the plugin expects the Wanteds > flattened or not, but ideally GHC would just always pass them flattened. > I'm unaware of any established policy about interface changes at this > level, whether we've somehow committed to backwards-compatibility here or > not. Anyone know? > > Plugin authors: would you look over the ticket comments and share your > thoughts here? We're looking to build some sort of consensus about how to > proceed without shocking the API users. > > Thank you for your time. -Nick >
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
