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 <[email protected]> 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:[email protected]] On Behalf Of Reid > | Barton > | Sent: 05 January 2017 15:27 > | To: [email protected] > | 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 > | [email protected] > | > 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 _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
