[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