Re: Request for feedback: deriving strategies syntax

Hi Simon,

* Current specification is here: ...

It's in a Haskell wiki page: [1]. This summarizes the current proposed syntax for -XDerivingStrategies, how GHC will choose a strategy in the absence of an explicit strategy, and also goes over some alternative syntaxes that have been proposed previously for the sake of archiving.

* Patch is here: ... (complete?)

It's on Phabricator: [2].

* Unresolved issues? Ready to review?

It's ready for review. It's incorporated all of the changes discussed on this e-mail thread, including renaming the "builtin" strategy to "bespoke", and including a link to the DerivingStrategies wiki in a Note. You left some inline comments on an earlier draft—I responded to some of them with questions [3], since I wasn't clear what you were asking. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategies [2] https://phabricator.haskell.org/D2280 [3] https://phabricator.haskell.org/D2280#inline-20129 On Thu, Aug 11, 2016 at 6:36 AM, Simon Peyton Jones wrote:

Ryan

I've been on holiday, and there's been a lot of traffic on this deriving-strategy thread.

Would you like to send an email summarising the state of play. Eg * Current specification is here: ... * Patch is here: ... (complete?) * Unresolved issues? Ready to review?

Thanks

Simon

| -----Original Message----- | From: Ryan Scott [mailto:ryan.gl.scott@gmail.com] | Sent: 02 August 2016 23:59 | To: Simon Peyton Jones | Cc: Richard Eisenberg ; Andres Loeh ; GHC developers | Subject: Re: Request for feedback: deriving strategies syntax | | Thanks for the feedback, everyone! I've typed up the developments so | far in the DerivingStrategies Haskell wiki page [1]. | | Here's what seems to be the consensus: | | * The syntax in which actual keywords are used to designate deriving | strategies was the clear favorite. | * In particular, a slight edge goes to the form in which multiple | deriving clauses can be placed after a datatype, and each `deriving` | clause has its own (optional) strategy keyword, as opposed to putting | the keyword directly in front of the derived type. | * The `builtin` keyword was poorly received. There isn't a obvious | candidate to replace it, and several of us like the word `bespoke`, so | it looks like `bespoke` will be the replacement. (If someone ends up | complaining about it, we've got several other choices.) | | | Any other questions or comments? | | Ryan S. | ----- | [1] | https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrate | gies | | On Mon, Jul 18, 2016 at 5:54 PM, Simon Peyton Jones | wrote: | > I'm not following all the details here, and I do not feel strongly | about syntax; but I do hope that you'll update the wiki page to reflect | the discussion. | > | > Thanks | > | > Simon | > | > -----Original Message----- | > From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Ryan | Scott | > Sent: 18 July 2016 15:00 | > To: Richard Eisenberg | > Cc: Andres Loeh ; GHC developers | > Subject: Re: Request for feedback: deriving strategies syntax | > | > Andres, | > | >> The objects probably shouldn't be type synonyms, but they could be | >> special datatypes or type families, perhaps. | > | > I considered that - we already have some special datatypes, type | families, and type classes currently. However, neither datatypes nor | type families are allowed to appear as the outermost type in an instance | declaration (unless we bake in a very prominent exception to this rule), | and if we imbued type classes with this magic, one might think that | "deriving (GND Eq)" means we're deriving an instance for the magical GND | class, not Eq. So those approaches don't sound satisfying to me on a | cursory examination. | > | > Richard, | > | >> The one idea I can suggest in this space (somewhat tongue-in-cheek, | >> but feel free to take it seriously) is `bespoke` | > | > It might be a tongue-in-cheek suggestion, but I _really_ like it. It | captures the intended semantics better than any other previous | suggestion, I think. And we're already going to be appropriating a new | keyword with "anyclass", so why not take "bespoke" as well? :) | > | > Please stop me if I've slipped into madness here. | > | >> I thought about verbosity here, and it's not clear which one is more | verbose. For example, I frequently define a new newtype and then wish to | use GND to derive a whole host of instances. In this case (is it | common?), `deriving (X, Y) deriving newtype (A,B,C,D,E,F)` is shorter | than putting newtype on each class name. | > | > That's a good point. Another thing to consider is that I suspect in | 90% of the time, users are only going to be reaching for - | XDerivingStrategies in the scenario when they enable both - | XGeneralizedNewtypeDeriving and -XDeriveAnyClass. That will happen when | they want to derive instances for newtypes, and as you said, you | typically derive several instances at a time when defining newtypes. | > Therefore, it seems less noisy to factor out the deriving strategy | names so that readers can tell at a glance which batch of instances are | newtype-derived and which are anyclass-derived, instead of having to | read a keyword before every single type. | > | > Plus, on a superficial level, I like keeping the deriving strategy | name outside of the parentheses. I think it makes clear that these | keywords aren't modifying the type we're deriving, only the means by | which we're deriving it. Of course, you may feel differently than I do, | so please speak up if you disagree! | > | > | > Ryan S. | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs@haskell.org | > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.has | kell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cea562a7e9e494f07c | ede08d3af13cbc7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=rKTWOkEZsKU | dDOTnk7WL2BNx1lf36uelef4JDg0pX44%3d