Hi Ryan and everyone else.
Thanks for summarizing the options.
As I've said before, I don't like design option 1 because I think
influencing program semantics in such a drastic way isn't what pragmas
should be used for.
Re design option 2, what I dislike about it is indeed that the idea is
that Builtin/GND/DAC are type synonyms, which aren't supposed to have
any meaning in this context. I do like, however, that they're
"first-class" objects in this proposal, and that it'd be easy to use
something like the kind system to make more of them, and that it'd
open up a road to a future where we perhaps could programmatically add
more options. The objects probably shouldn't be type synonyms, but
they could be special datatypes or type families, perhaps. I need to
think about this some more. It ties in into some other things I'd
consider nice-to-have, but I need more time to put that into a
coherent story.
There's nothing obviously wrong with option 3, but it seems relatively
verbose (I'd prefer Richard's syntax), and feels more ad-hoc. I don't
mind "builtin" to refer to the deriving mechanism, but again, I also
don't mind Richard's suggestion of using "bespoke". Another suggestion
would be to use "magic".
Cheers,
Andres
On Sun, Jul 17, 2016 at 4:02 AM, Ryan Scott
I'm pursuing a fix to Trac #10598 [1], an issue in which GHC users do not have fine-grained control over which strategy to use when deriving an instance, especially when multiple extensions like -XGeneralizedNewtypeDeriving and -XDeriveAnyClass are enabled simultaneously. I have a working patch up at [2] which would fix the issue, but there's still a lingering question of what the right syntax is to use here. I want to make sure I get this right, so I'm requesting input from the community.
To condense the conversation in [1], there are three means by which you can derive an instance in GHC today:
1. -XGeneralizedNewtypeDeriving 2. -XDeriveAnyClass 3. GHC's builtin algorithms (which are used for deriving Eq, Show, Functor, Generic, Data, etc.)
The problem is that it's sometimes hard to know which of the three will kick in when you say `deriving C`. To resolve this ambiguity, I want to introduce the -XDerivingStrategies extension, where a user can explicitly request which of the above ways to derive an instance.
Here are some of the previously proposed syntaxes for this feature, with their perceived pros and cons:
----- Pragmas * Examples: - newtype T a = T a deriving ({-# BUILTIN #-} Eq, {-# GND #-} Ord, {-# DAC #-} Read, Show) - deriving {-# BUILTIN #-} instance Functor T * Pros: - Backwards compatible - Requires no changes to Template Haskell * Cons: - Unlike other pragmas, these ones can affect the semantics of a program ----- Type synonyms * Examples: - newtype T a = T a deriving (Builtin Eq, GND Ord, DAC Read, Show) - deriving instance Builtin (Functor T) * Pros: - Requires no Template Haskell or parser changes, just some magic in the typechecker - Backwards compatible (back to GHC 7.6) * Cons: - Some developers objected to the idea of imbuing type synonyms with magical properties ----- Multiple deriving clauses, plus new keywords * Examples: - newtype T a = T a deriving Show deriving builtin instance (Eq, Foldable) deriving newtype instance Ord deriving anyclass instance Read - deriving builtin instance Functor T * Pros: - Doesn't suffer from the same semantic issues as the other suggestions - (Arguably) the most straightforward-looking syntax * Cons: - Requires breaking changes to Template Haskell - Changes the parser and syntax significantly
Several GHC devs objected to the first two of the above suggestions in [1], so I chose to implement the "Multiple deriving clauses, plus new keywords" option in [2]. However, I'd appreciate further discussion on the above options, which one you prefer, and if you have other suggestions for syntax to use.
Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/10598 [2] https://phabricator.haskell.org/D2280 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs