Request for feedback: deriving strategies syntax

Thu Aug 4 00:26:48 UTC 2016

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 <eir at cis.upenn.edu>
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 <ryan.gl.scott at gmail.com> 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 at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160803/48e8b2a4/attachment-0001.html>