Hello, I haven't worked on that stuff in Haskell for a long time, but here are some thoughts: - I think plugins should generally be agnostic to the form of the constraints they are given, thus flattening or not should not affect them---after all, the user might have written the constraints in the "flattened" form in the first place. So I think a plugin needs to convert the constraints to whatever form it assumes anyways. - I always thought that derived constraints were a pretty clever way for disseminating information in the constraint solver, is there a note somewhere on what's going to be the new mechanism?
-Iavor On Thu, Nov 19, 2020 at 2:21 AM Christiaan Baaij <christiaan.ba...@gmail.com> wrote: > I always forget what flattening did/does. Is it the thing where it turns a > "complex" type family application: > > F (G y) (H z) ~ a > > into: > > G y ~ p > H z ~ q > F p q ~ a > > ? > > If so, then I'm all for removing that. Since I actually wrote/hacked a > function that "reverts" that process (for [G]ivens only): > https://hackage.haskell.org/package/ghc-tcplugins-extra-0.4/docs/src/GHC.TcPluginM.Extra.html#flattenGivens > Which I use in all of my plugins. (PS it should perhaps be called > "unflattenGiven"? like I said, I always get confused about flatten vs > unflatten). > > On Thu, 19 Nov 2020 at 05:20, Richard Eisenberg <r...@richarde.dev> wrote: > >> Hi all, >> >> I'm hard at work on two significant refactorings within GHC's constraint >> solver. The first is at >> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4149. It removes >> flattening meta-variables and flattening skolems. This is a very nice >> simplification. Instead, it just reduces type families directly. My other >> patch (held up by the first) is at >> https://gitlab.haskell.org/ghc/ghc/-/tree/wip/derived-refactor and will >> remove Derived constraints, to be replaced by a little bit of cleverness in >> suppressing certain confusing error messages. My guess is that either or >> both of these will invalidate the current behavior of type-checker plugins. >> Sadly, this is not just a case of finding a new function that replicates >> the old behavior -- enough is changing under the hood that you might >> actually have to rewrite chunks of your code. >> >> I have never written a type-checker plugin, and so I don't currently have >> advice for you. But if you are a plugin author affected by this change and >> want help, please reach out -- I would be happy to walk you through the >> changes, and then hopefully make a little video explaining the process to >> other plugin authors. >> >> Neither patch will make it for 9.0, but I expect both to be in 9.2. There >> may be more where this came from ( >> https://gitlab.haskell.org/ghc/ghc/-/issues/18965) in the future, but >> it's all for a good cause. >> >> (I have bcc'd plugin authors that I'm aware of. Just adding this in case >> you're surprised at receiving this email.) >> >> Thanks, >> Richard > > _______________________________________________ > 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