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 <ryan.gl.sc...@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@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
