[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