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 <simo...@microsoft.com> 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.sc...@gmail.com] > | Sent: 02 August 2016 23:59 > | To: Simon Peyton Jones <simo...@microsoft.com> > | Cc: Richard Eisenberg <e...@cis.upenn.edu>; Andres Loeh <mail@andres- > | loeh.de>; GHC developers <ghc-devs@haskell.org> > | 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 > | <simo...@microsoft.com> 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-boun...@haskell.org] On Behalf Of Ryan > | Scott > | > Sent: 18 July 2016 15:00 > | > To: Richard Eisenberg <e...@cis.upenn.edu> > | > Cc: Andres Loeh <m...@andres-loeh.de>; GHC developers <ghc- > | d...@haskell.org> > | > 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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
