[GHC] #13072: Move large tuples to a separate module in base
GHC
ghc-devs at haskell.org
Fri Jan 6 17:50:35 UTC 2017
#13072: Move large tuples to a separate module in base
-------------------------------------+-------------------------------------
Reporter: rwbarton | Owner: rwbarton
Type: task | Status: new
Priority: normal | Milestone: 8.2.1
Component: libraries/base | Version: 8.1
Resolution: | Keywords:
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 rwbarton):
So I have a branch for this that builds successfully. However if I add
instances to `GHC.LargeTuple`, then the instances aren't visible
automatically. Using `:i` brings the instances into scope somehow. A
sample ghci session:
{{{
Prelude> let x = (1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1) in x == x
<interactive>:3:46: error:
• Ambiguous type variable ‘p0’ arising from a use of ‘x’
prevents the constraint ‘(Num p0)’ from being solved.
Probable fix: use a type annotation to specify what ‘p0’ should be.
These potential instances exist:
instance Num Integer -- Defined in ‘GHC.Num’
instance Num Double -- Defined in ‘GHC.Float’
instance Num Float -- Defined in ‘GHC.Float’
...plus two others
(use -fprint-potential-instances to see them all)
• In the first argument of ‘(==)’, namely ‘x’
In the expression: x == x
In the expression:
let x = (1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) in x == x
<interactive>:3:46: error:
• No instance for (Eq
(a0, b0, c0, d0, e0, f0, g0, h0, i0, j0, k0, l0,
m0, n0, o0, p0))
arising from a use of ‘==’
• In the expression: x == x
In the expression:
let x = (1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) in x == x
In an equation for ‘it’: it = let x = ... in x == x
Prelude> :i (,,,,,,,,,,,,,,,)
data (,,,,,,,,,,,,,,,) a b c d e f g h i j k l m n o p
= (,,,,,,,,,,,,,,,) a b c d e f g h i j k l m n o p
-- Defined in ‘GHC.LargeTuple’
instance [safe] (Bounded p, Bounded o, Bounded n, Bounded m,
Bounded l, Bounded k, Bounded j, Bounded i, Bounded h,
Bounded g,
Bounded f, Bounded e, Bounded d, Bounded c, Bounded b,
Bounded a) =>
Bounded (a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p)
-- Defined in ‘GHC.LargeTuple’
instance [safe] (Eq p, Eq o, Eq n, Eq m, Eq l, Eq k, Eq j, Eq i,
Eq h, Eq g, Eq f, Eq e, Eq d, Eq c, Eq b, Eq a) =>
Eq (a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p)
-- Defined in ‘GHC.LargeTuple’
instance [safe] (Ord p, Ord o, Ord n, Ord m, Ord l, Ord k, Ord j,
Ord i, Ord h, Ord g, Ord f, Ord e, Ord d, Ord c, Ord b,
Ord a) =>
Ord (a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p)
-- Defined in ‘GHC.LargeTuple’
Prelude> let x = (1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1) in x == x
True
}}}
Simon, do I need to apply a similar refactoring as you did in
ffc21506894c7887d3620423aaf86bc6113a1071 ("Refactor tuple constraints")? I
see `ConstraintTuple` is treated differently in `tcTupleTyCon`, which
looks relevant.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13072#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list