[GHC] #12928: Too easy to trigger CUSK condition using TH
GHC
ghc-devs at haskell.org
Mon Dec 5 21:08:02 UTC 2016
#12928: Too easy to trigger CUSK condition using TH
-------------------------------------+-------------------------------------
Reporter: int-index | Owner:
Type: feature request | Status: new
Priority: high | Milestone:
Component: Compiler (Type | Version: 8.0.1
checker) |
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: GHC rejects | Unknown/Multiple
valid program | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by goldfire):
ezyang is right -- it would be sound. But it would defeat the purpose of
CUSKs.
The idea with CUSKs is that they allow a user to specify when everything
about the kind of a type-level definition (datatype, newtype, class,
family, type synonym) is known, without any inference. When a CUSK is
available, GHC can then use polymorphic recursion and other fancy features
while checking the type. Without a CUSK, though, inference with
polymorphic recursion is impossible.
Here is an example:
{{{
type family F (a :: k) where
F Int = Bool
}}}
What's the kind of `F`? There are at least two possibilities: `k -> Type`
and `k -> k`. Neither is more general than the other. Instead of guessing
between these (and others that use kind families!), GHC rejects the
definition as lacking a CUSK.
Is this an example of polymorphic recursion? Sort of. You can see it as
polymorphic recursion if we consider that we're defining `F` but the
occurrence of `F` in the equation is specialized to operate at kind
`Type`. So it falls under this whole umbrella.
Getting back to the original question: we ''could'' generalize here. But
then type inference would become unpredictable.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12928#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list