[GHC] #13072: Move large tuples to a separate module in base

GHC ghc-devs at haskell.org
Mon Jan 9 16:24:51 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):

 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


More information about the ghc-tickets mailing list