#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): I have this nearly working following the the approach you outlined above, but there's one point I'm not sure about having to do with type family instance checking. Originally I had `Prelude` importing `GHC.LargeTuple`, but since `GHC.LargeTuple` defines type family instances (for `Rep`) it was marked as a "family instances" import of `Prelude`; which meant that any time the user loaded an interface file with their own type family instances, GHC would read the interface file for `GHC.LargeTuple` too to make sure there were no conflicts. Not good. So I figured out that `Prelude` doesn't actually need to import `GHC.LargeTuple`, since the type checker will load the latter when needed with `checkWiredInTyCon`. Now everything works great. However, I'm not sure about the type family soundness situation. Consider that a user can write an instance that overlaps with the ones from `GHC.LargeTuple` without mentioning a tuple, such as {{{#!hs instance Generic (a b c d e f g h i j k l m n o p q r s t) where type Rep (a b c d e f g h i j k l m n o p q r s t) = X -- overlaps with a 19-tuple. -- Can even replace `b` with a data type defined in this module, -- so it wouldn't be an orphan }}} I think it's still impossible to use both instances in the same program without mentioning a large tuple constructor and therefore loading the `GHC.LargeTuple` interface file and finding the conflict; but I'm not 100% sure (what if the uses of the two type family instances are in separate packages, etc.) Thoughts? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13072#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler