Introduce Concrete# for representation polymorphism checks
This MR replaces the previous MR !6164 (closed), which was becoming too large.
This patch moves the representation polymorphism checks from the desugarer to the typechecker, by introducing a magic Concrete#
predicate, and emitting Concrete#
Wanted constraints to rule out representation polymorphism where it isn't allowed. A broad outline in laid out in the wiki page FixedRuntimeRep.
This only implements PHASE 1 of the plan outlined on the wiki page: we don't allow Concrete#
constraints to be rewritten (only zonked), so this doesn't add support for type families in RuntimeRep
s.
Fixes these tickets:
Unresolved issues:
-
Clarify the notions of representation-polymorphic and levity-polymorphic in all the notes that talk about these. -
Do we keep the boxed typeclass constaint Concrete
, when it is only used for Backpack? I've removed it, as further thought seemed to indicate that it does make good sense forAbstractTyCon
s to always be considered concrete; not doing so makes it difficult to implement Core Lint correctly. -
Re-use inert_irreds
instead of adding a new fieldinert_specials
to the inert set. -
Provide a water-tight argument to ensure that, even in PHASE 2, any implementation of an abstract TyCon
in a signature file is indeed concrete. -
Check that Ed Kmett's unboxed
package can indeed compile. We haveRepPolyBackpack2.bkp
in the test-suite that does something very similar, so in theory I'm rather confident we'll be OK, but I've had issues actually compiling Ed's package.
Edited by sheaf