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 <[email protected]> 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 <[email protected]> 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 > > [email protected] > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
