[GHC] #10451: Constraint tuple regression in HEAD

[GHC]

#10451: Constraint tuple regression in HEAD
-------------------------------------+-------------------------------------
        Reporter:  darchon           |                   Owner:
            Type:  bug               |                  Status:  new
        Priority:  normal            |               Milestone:
       Component:  Compiler          |                 Version:  7.11
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |  ConstraintKinds
 Type of failure:  GHC rejects       |            Architecture:
  valid program                      |  Unknown/Multiple
      Blocked By:                    |               Test Case:
 Related Tickets:                    |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by simonpj):

 Yes, you are right about the cause.

  * At very least there should be a civilised error message. I'll fix that.

  * It'd be fine to increase the limit.  62 is also a pretty strange limit,
 but I think that provided the error message is helpful pretty much any
 limit is ok, since the workaround (nesting) is very straightforward.  For
 "deriving Eq" we go up to 16-tuples, even though tuples themselves go up
 to 62, so perhaps 16 would do.

  * Auto-nesting would be nice, but I think it's probably more pressing for
 ordinary tuples.  I've often thought about doing so, but it's hard to do
 consistently.  For example, suppose (extreme case) that we only supported
 pairs.  Then if someone wrote
 {{{
 f (x,y,z) = e
 }}}
   we'd nest the pair so that the "real" type of `f` is `(Int, (Int,Int))
 -> blah`.  But that would be a confusing type to display.   And it would
 be hard to stop you applying `f` to a nested tuple, e.g. `f (1, (2,3))`.
 GHC doesn't have a notion of a "user type" and an "implementation type".
 It's never been pressing enough to jump into this particular swamp.

 Concretely I propose:
  * Increase the max arity to 16
  * Give a civilised error message if you exceed it
  * Document the limit

 acowley: can you explain more about ''how'' you bump up against the 62
 limit. Do you really write such large tuples by hand? Or does some program
 write them?  In which case, is nesting difficult?

 Simon

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