Re: Request for feedback: deriving strategies syntax

It has the benefit that nothing lowercase would ever derive in that position so it is a strict extension of the current syntax. So even it builtin or whatever is a conditional keyword like qualified and as, I don't see any issues with it. 'bespoke' does make me smile, though. =) -Edward On Sun, Jul 17, 2016 at 10:24 PM, Richard Eisenberg wrote:

Of the three options from Ryan's first email in this thread, only the third is palatable to me (with the separate `deriving` clauses).

I would like to mention that I don't see any real obstacles to something like

...

newtype ... deriving (Eq, default ToJSON, builtin Ord, newtype Monoid)

That is, one `deriving` clause where each element is optionally prefixed with a keyword. On the ticket (#10598), it is suggested that parsing these would be hard. I agree that parsing these would be annoying, but I do not think that they are actually ambiguous. Avoiding a few hours of pain in the parser should not be our motivation for choosing a syntax we will all live with for years. For `default` and `newtype`, parsing is actually easy. If we want to keep the `builtin` pseudo-keyword, we could always parse as a type and then have some non-parser code examine the resulting AST and sort it out. (This is done in several other dark corners of the parser already.)

Separately, I'm not enamored of the `builtin` keyword. The one idea I can suggest in this space (somewhat tongue-in-cheek, but feel free to take it seriously) is `bespoke` -- after all, each "builtin" instance must be generated by code written specifically for that class, which fits the English definition of bespoke nicely. "Which deriving mechanism do want?" "The bespoke one, please." And then GHC can boast that it has the classiest keyword of any programming language. :)

Richard

On Jul 16, 2016, at 10:02 PM, Ryan Scott wrote:

...

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

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs