> 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? :)
It doesn't have to be a "keyword" in the sense of reservedid, right? >> 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. Yes, you've convinced me that putting the strategy once in front is at least not worse. > 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! The very first times when I've talked to others about this feature, I think I've always used "deriving (Eq via bespoke, Monad via gnd)" as syntax, but yes, in general I agree that keeping it completely out of the parentheses may be a mild advantage. Cheers, Andres _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
