Large tuple strategy

[Simon Peyton Jones]

|  It occurred to me that rather than moving just these instances to a new
|  module, we could move the large tuples themselves to a new module
|  Data.LargeTuple and put the instances there.

Yes, that's what I intended to suggest.  Good plan.

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Reid
|  Barton
|  Sent: 05 January 2017 15:27
|  To: ghc-devs at haskell.org
|  Subject: Large tuple strategy
|  
|  Hi all,
|  
|  https://phabricator.haskell.org/D2899 proposes adding Generic instances for
|  large tuples (up to size 62). Currently GHC only provides Generic instances
|  for tuples of size up to 7. There's been some concern about the effect that
|  all these instances will have on compilation time for anyone who uses
|  Generics, even if they don't actually use the new instances.
|  
|  There was a suggestion to move these new instances to a separate module, but
|  as these instances would then be orphans, I believe GHC would have to read
|  the interface file for that module anyways once Generic comes into scope,
|  which would defeat the purpose of the split.
|  
|  It occurred to me that rather than moving just these instances to a new
|  module, we could move the large tuples themselves to a new module
|  Data.LargeTuple and put the instances there. The Prelude would reexport the
|  large tuples, so there would be no user-visible change.
|  According to my experiments, GHC should never have to read the
|  Data.LargeTuple interface file unless a program actually mentions a large
|  tuple type, which is presumably rare. We could then also extend the existing
|  instances for Eq, Show, etc., which are currently only provided through 15-
|  tuples.
|  
|  A nontrivial aspect of this change is that tuples are wired-in types, and
|  they currently all live in the ghc-prim package. I'm actually not sure why
|  they need to be wired-in rather than ordinary types with a funny-looking
|  name. In any case I need to look into this further, but the difficulties
|  here don't seem to be insurmountable.
|  
|  Does this seem like a reasonable plan? Anything important I have missed?
|  
|  Regards,
|  Reid Barton
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell
|  .org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cd3262b1204df407f65ce08d4357f4b
|  d8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636192268229980651&sdata=NV%
|  2BaCgD7Xo5EIwuL5cZaTrCBHihNxAiZvT0VCNQl6Z8%3D&reserved=0