[GHC] #15710: Should GHC accept a type signature that needs coercion quantification?

[GHC]

#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 goldfire):

 Yes, I'm arguing both sides -- but with good reason. `t1 ~# t2` is not a
 constraint ''today'', and thus it shouldn't respond to `isPredTy`. But
 this ticket is all about ''tomorrow'', when I do think it could become a
 constraint.

 Would we be more efficient if constraints could be strict and unboxed? I
 imagine "yes". If so, then the current story isn't working as well as it
 could be.

 As for tupling: we could make `( ... )` be an unboxed tuple if it's
 written to the left of `=>`. In the end, I just think of the parens and
 commas as concrete syntax for some unspecified abstract syntax that
 handles sets of constraints here. (This is not how I think of the argument
 to `Dict`, say, where order suddenly matters.)

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15710#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler