Request for feedback: deriving strategies syntax

[Moritz Angermann]

I was going to propose this as well! Would probably provide valuable
practicability feedback to the proposed proposal process.

- Moritz

> On Jul 17, 2016, at 5:10 PM, Oleg Grenrus <oleg.grenrus at iki.fi> wrote:
> 
> Should we test drive https://github.com/ghc-proposals/ghc-proposals
> on this proposal?
> 
> - Oleg
> 
>> On 17 Jul 2016, at 05:02, 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

————————————————— 
Moritz Angermann
+49 170 54 33 0 74
moritz at lichtzwerge.de

lichtzwerge GmbH
Raiffeisenstr. 8
93185 Michelsneukirchen

Amtsgericht Regensburg HRB 14723
Geschäftsführung: Moritz Angermann, Ralf Sangl
USt-Id: DE291948767

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail
ist nicht gestattet.
This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail.
Any unauthorized copying, disclosure or distribution of the material in
this e-mail is strictly forbidden.