Large tuple strategy

[Reid Barton]

OK, I filed https://ghc.haskell.org/trac/ghc/ticket/13072 for this.

Regards,
Reid Barton

On Thu, Jan 5, 2017 at 10:28 AM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:
> |  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