| 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@haskell.org] On Behalf Of Reid | Barton | Sent: 05 January 2017 15:27 | To: ghc-devs@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@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

Reid Barton writes:

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.

Good catch Reid! Cheers, - Ben