<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 19, 2020, at 12:40 PM, Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" class="">iavor.diatchki@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hello,<div class=""><br class=""></div><div class="">I haven't worked on that stuff in Haskell for a long time, but here are some thoughts:</div><div class="">  - 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.</div><div class="">  - 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?</div></div></div></blockquote><div><br class=""></div><div>This Note (<a href="https://gitlab.haskell.org/ghc/ghc/-/blob/wip/derived-refactor/compiler/GHC/Tc/Types/Constraint.hs#L1678" class="">https://gitlab.haskell.org/ghc/ghc/-/blob/wip/derived-refactor/compiler/GHC/Tc/Types/Constraint.hs#L1678</a>) is the best I can offer, though it may be out of date. In the final version of the patch, that Note will naturally be updated. Essentially, the new plan is just to use Wanteds instead of Deriveds, which will achieve the same goal (but do not need to be distinct from Deriveds).</div><div><br class=""></div><div>Richard</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">-Iavor</div><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 19, 2020 at 2:21 AM Christiaan Baaij <<a href="mailto:christiaan.baaij@gmail.com" class="">christiaan.baaij@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div class="">I always forget what flattening did/does. Is it the thing where it turns a "complex" type family application:<br class=""><br class=""></div><div class="">F (G y) (H z) ~ a<br class=""></div><div class=""><br class=""></div><div class="">into:<br class=""><br class=""></div><div class="">G y ~ p</div><div class="">H z ~ q</div><div class="">F p q ~ a</div><div class=""><br class=""></div><div class="">?</div><div class=""><br class=""></div><div class="">If so, then I'm all for removing that. Since I actually wrote/hacked a function that "reverts" that process (for [G]ivens only): <a href="https://hackage.haskell.org/package/ghc-tcplugins-extra-0.4/docs/src/GHC.TcPluginM.Extra.html#flattenGivens" target="_blank" class="">https://hackage.haskell.org/package/ghc-tcplugins-extra-0.4/docs/src/GHC.TcPluginM.Extra.html#flattenGivens</a><br class=""></div><div class="">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).</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 19 Nov 2020 at 05:20, Richard Eisenberg <<a href="mailto:rae@richarde.dev" target="_blank" class="">rae@richarde.dev</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br class="">
<br class="">
I'm hard at work on two significant refactorings within GHC's constraint solver. The first is at <a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4149" rel="noreferrer" target="_blank" class="">https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4149</a>. 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 <a href="https://gitlab.haskell.org/ghc/ghc/-/tree/wip/derived-refactor" rel="noreferrer" target="_blank" class="">https://gitlab.haskell.org/ghc/ghc/-/tree/wip/derived-refactor</a> 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.<br class="">
<br class="">
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.<br class="">
<br class="">
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 (<a href="https://gitlab.haskell.org/ghc/ghc/-/issues/18965" rel="noreferrer" target="_blank" class="">https://gitlab.haskell.org/ghc/ghc/-/issues/18965</a>) in the future, but it's all for a good cause.<br class="">
<br class="">
(I have bcc'd plugin authors that I'm aware of. Just adding this in case you're surprised at receiving this email.)<br class="">
<br class="">
Thanks,<br class="">
Richard</blockquote></div>
_______________________________________________<br class="">
ghc-devs mailing list<br class="">
<a href="mailto:ghc-devs@haskell.org" target="_blank" class="">ghc-devs@haskell.org</a><br class="">
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank" class="">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></body></html>