Request for feedback: deriving strategies syntax

Ryan Scott ryan.gl.scott at gmail.com
Tue Aug 2 22:59:17 UTC 2016


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/DerivingStrategies

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.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cea562a7e9e494f07cede08d3af13cbc7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=rKTWOkEZsKUdDOTnk7WL2BNx1lf36uelef4JDg0pX44%3d


More information about the ghc-devs mailing list