PSA: type checker plugins to be affected by upcoming changes to GHC

[Iavor Diatchki]

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.baaij at 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 <rae at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201119/0d245d3a/attachment.html>