Re: Request for feedback: deriving strategies syntax

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 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...

...

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" 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

...

...

...

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 javascript:;> wrote:

...

Oleg Grenrus 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

On Sun, Jul 17, 2016 at 8:59 AM, Elliot Cameron javascript:;> wrote: this 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@haskell.org javascript:; http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

---

ghc-devs mailing list ghc-devs@haskell.org javascript:; http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs