tcplugins-zurihac2020 VS typelevel-rewrite-rules

[1] https://github.com/nfrisby/tcplugins-zurihac2020/blob/master/outline.md [2] https://www.youtube.com/watch?v=sE1qWyQWWVY

Therefore, one convoluted way to integrate your language into the ghc pipeline would be as follows. Define a magic typeclass:

I encountered a similar issue in typelevel-rewrite-rules. The user writes type PlusAssoc a b c = ((a + b) + c) ~ (a + (b + c)) to indicate that they want a type like (2 + x) + 1 to be rewritten to 2 + (x + 1). Thus, I want to be able to look at (2 + x) + 1 and learn that yes, it matches the pattern (a + b) + c, with the substitution a = 2, b = x, c = 1.

Nice! Thanks for including a comparison with my package typelevel-rewrite-rules. Since my package indeed struggles with infinite loops introduced by self-triggering rewrite rules, I would like to better understand why your package doesn't suffer from that same problem.

When writing a typechecker plugin, you can eliminate constraints from the user's program by providing an implementation of the corresponding dictionary. The way you provide that dictionary to ghc is by providing a core expression; for example, this evCast futureDict co expression has type EvTerm, whose first constructor takes an EvExpr, which is a synonym for CoreExpr.

Until then, I guess we can simply poll. Here's a GitHub Action I wrote today which checks if the latest report for a given package includes a failure: https://github.com/gelisam/typelevel-rewrite-rules/blob/main/.github/workflows/check-hackage-matrix.yml