[GHC] #15710: Should GHC accept a type signature that needs coercion quantification?
GHC
ghc-devs at haskell.org
Mon Oct 8 08:20:49 UTC 2018
#15710: Should GHC accept a type signature that needs coercion quantification?
-------------------------------------+-------------------------------------
Reporter: simonpj | Owner: (none)
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 8.6.1
Resolution: | Keywords: TypeInType
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by simonpj):
Tupling: yes `f :: (Num a, Ord a) => blah` is ''already'' syntactic sugar
for `f :: Num a => Ord a => blah`. But I'm more concerned about
{{{
type C a b = (Num a, a ~ b)
}}}
and here it'd be much trickier (and unprincipled) to switch to unboxed
tuples. Moreover, we do lots of constraint abstraction
{{{
data Dict c where
Dict :: c => Dict c
}}}
and we can't instantiate that polymorphic `c` with an unboxed tuple.
So yes, I think we could have `Constraint` and `Constraint#` just as we
have `Int` and `Int#`. But it's very uncomfortable to have to use `a ~#
b` in a type if (but only if) the constraint is used in a dependent way.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15710#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list