That's an interesting thought. I only chose "builtin" since it has a history of being used for this purpose within GHC's internals [1].
That being said, "standard" does have its own problems, since several of the typeclasses covered by it (Data, Generic(1), Lift, etc.) are not part of any Haskell standard. (I don't know if that's the connotation you aimed for, but that's what I glean from reading it.) I want something that conveys the fact that when deriving this instance, GHC is using some domain-specific knowledge to derive the instance. If not "builtin" or "standard", some other possibilities I can think of are "native", "original", or "specialized". I don't know if I have a strong preference for one in particular. Another suggestion previously tossed around was "default", but I decided against that since that keyword is also used in -XDefaultSignatures, which very much has a generic programming connotation, and I didn't want users to confuse it with the -XDeriveAnyClass strategy. Ryan S. ----- [1] http://git.haskell.org/ghc.git/blob/5df92f6776b31b375a80865e7db1f330d929c18f:/compiler/typecheck/TcGenDeriv.hs#l116 On Sun, Jul 17, 2016 at 8:59 AM, Elliot Cameron <[email protected]> wrote: > Just a quick thought: The term "built-in" seems a bit myopic IMO since all > these extensions are in a sense built-in, and especially if any of them make > it into Haskell 2020. I wonder if "standard" would be better or something > similar. > > > On Jul 17, 2016 08:57, "Ryan Scott" <[email protected]> wrote: >> >> Ben, >> >> > I think it would be a great idea. That being said, given that it's not >> > be approved yet, I'm in no position to require it. Ryan, I'll leave this >> > call up to you. If you would like to write up a proposal using the >> > template in the repository then by all means let's give it a try. >> > If not, then no worries; we can continue here. >> >> I hadn't thought of using ghc-proposals for this, and since it's still >> in a nascent state, I'll opt to continue using the GHC devs mailing >> list for this dicussion. >> >> >> Alexey, >> >> > I can't see how this doesn't require changes to Template Haskell. >> >> You are correct, I got my wires crossed when trying to recall the >> details. I think what I (sloppily) remembered was that in an earlier >> revision of https://phabricator.haskell.org/D2280, I had implemented a >> pragma-based approach that didn't require a language extension. But I >> now consider that a mistake, so I've introduced the >> -XDerivingStrategies extension, which should be required regardless of >> what syntax we decide to adopt. >> >> Ryan S. >> >> On Sun, Jul 17, 2016 at 6:36 AM, Ben Gamari <[email protected]> wrote: >> > Oleg Grenrus <[email protected]> writes: >> > >> >> Should we test drive https://github.com/ghc-proposals/ghc-proposals >> >> <https://github.com/ghc-proposals/ghc-proposals> on this proposal? >> >> >> > I think it would be a great idea. That being said, given that it's not >> > be approved yet, I'm in no position to require it. Ryan, I'll leave this >> > call up to you. If you would like to write up a proposal using the >> > template in the repository then by all means let's give it a try. >> > If not, then no worries; we can continue here. >> > >> > Cheers, >> > >> > - Ben >> > >> _______________________________________________ >> ghc-devs mailing list >> [email protected] >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
