Request for feedback: deriving strategies syntax

[Ryan Scott]

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 <eacameron at gmail.com> 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" <ryan.gl.scott at gmail.com> 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 <ben at smart-cactus.org> wrote:
>> > Oleg Grenrus <oleg.grenrus at iki.fi> 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
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs