#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): Replying to [comment:6 simonpj]:
I don't think so. If M contains a type family instance, that instance should have been checked for consistency with `LargeTuple`. See `FamInst`: {{{ Note [Checking family instance consistency] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For any two family instance modules that we import directly or indirectly, we check whether the instances in the two modules are consistent, *unless* we can be certain that the instances of the two modules have already been checked for consistency during the compilation of modules that we import. }}} So `M` and `LargeTuple` have already been checked; so importers of `M` won't need to check. Right?
Interesting. If it's supposed to work this way in this scenario, it doesn't (and hasn't since 7.8.4 at least). Any user module that imports another user module that defines a type family instance forces reading the interface files in base that define type family instances. I'll take a closer look.
I might have written a function in Prelude that relies on the family instance
But that's true in every module. I don't understand. Are you proposing some kind of special case for LargeTuple? Or are you just saying that you were mistaken? Or what?
Okay, let me step back a bit. Originally I added an `import GHC.LargeTuple ()` to Prelude because I thought it was necessary and sufficient for GHC to know about the instances (both type family and class instances) in `GHC.LargeTuple` in programs that import Prelude. It turned out to be neither sufficient, nor necessary. It was not sufficient because the type checker was just pulling the `TyCon` for a large tuple out of thin air, in `tcExpr`. So, writing a large tuple expression did not cause `GHC.LargeTuple` to be read, and so the instances were not available. Adding the `checkWiredInTyCon` call to `tcExpr` fixed that. In fact since GHC has wired-in knowledge that large tuples live in `GHC.LargeTuple`, the `checkWiredInTyCon` call makes it read the `GHC.LargeTuple` interface file, which is conveniently where the instances are as well. So, now the `import GHC.LargeTuple ()` in Prelude served no actual purpose. Its only apparent effect was to mark `GHC.LargeTuple` as a "family instances" import of Prelude. What I was arguing above is that receiving the type family instances for large tuples should not be thought of as an effect of importing Prelude. Rather, it is as though any module which mentions a large tuple implicitly has an `import GHC.LargeTuple` added. There's no more need for Prelude to export the large tuple instances than there is for it to export instances defined by any other module in base that Prelude does not import. It just feels a bit odd at first because it seems natural to think of the large tuples as being imported from Prelude, rather than another place. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13072#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler