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