You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current treatment of type constructors by constraint inference is blatantly unsound, as we simply ignore the problem of constructor injectivity. As an example, following test causes a runtime exception:
abgruszecki
changed the title
Pattern matching does not consider injectivity of HK types
Unsoundness due to GADT bounds ignoring type (un)injectivity
Jan 2, 2019
[...] we distinguish the arrow of type constructors (matchable) from that of type families (unmatchable) and use two different symbols: (→), i.e. Haskell’s existing function arrow for the former, and (↠) for the latter. […] matchability corresponds to functions that are both generative and injective.
Works: ∀ (f :: ⋆ → ⋆). (f a ∼ f b) ⇒ a ~ b, because f must be an actual data type (like a class).
Fails: ∀ (f :: ⋆ ↠ ⋆). (f a ∼ f b) ⇒ a ~ b, because f might be any constant function, even a constant one, like Unsoundness above.
Current treatment of type constructors by constraint inference is blatantly unsound, as we simply ignore the problem of constructor injectivity. As an example, following test causes a runtime exception:
(https://github.com/dotty-staging/dotty/blob/d1fa5d73c4194448e1ab0d4d4e39a764b6e1f651/tests/run/gadt-injectivity-unsoundness.scala)
This was intentionally extracted out of #5611.
The text was updated successfully, but these errors were encountered: