Request for feedback: deriving strategies syntax

[Carter Schonwald]

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 <ryan.gl.scott at gmail.com> 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 <eacameron at gmail.com
> <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" <ryan.gl.scott at gmail.com
> <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 <ben at smart-cactus.org
> <javascript:;>> wrote:
> >> > Oleg Grenrus <oleg.grenrus at iki.fi <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
> >> ghc-devs at haskell.org <javascript:;>
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <javascript:;>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160717/9b6dd3a2/attachment-0001.html>