#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