Request for feedback: deriving strategies syntax

[Ryan Scott]

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
<simonpj at 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.scott at gmail.com]
> | Sent: 02 August 2016 23:59
> | To: Simon Peyton Jones <simonpj at microsoft.com>
> | Cc: Richard Eisenberg <eir at cis.upenn.edu>; Andres Loeh <mail at andres-
> | loeh.de>; GHC developers <ghc-devs at 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
> | <simonpj at 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-bounces at haskell.org] On Behalf Of Ryan
> | Scott
> | > Sent: 18 July 2016 15:00
> | > To: Richard Eisenberg <eir at cis.upenn.edu>
> | > Cc: Andres Loeh <mail at andres-loeh.de>; GHC developers <ghc-
> | devs at 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 at 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