Builtin sounds fine to me personally. WiredIn would also be valid , though that would overlap with some other ghc internals terminology.
When the deriving strategies extension isn't enabled , what will the new semantics be when more than one strategy applies? What's our new answer there ? On Sunday, July 17, 2016, Ryan Scott <[email protected]> wrote: > 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] > <javascript:;>> 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] > <javascript:;>> 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] > <javascript:;>> wrote: > >> > Oleg Grenrus <[email protected] <javascript:;>> 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] <javascript:;> > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > [email protected] <javascript:;> > 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
