Request for feedback: deriving strategies syntax

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
62 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Request for feedback: deriving strategies syntax

Ryan Scott
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: deriving strategies syntax

Oleg Grenrus
Should we test drive https://github.com/ghc-proposals/ghc-proposals
on this proposal?

- Oleg

On 17 Jul 2016, at 05:02, Ryan Scott <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

—————————————————
Moritz Angermann
+49 170 54 33 0 74
[hidden email]

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.

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: deriving strategies syntax

Alexey Vagarenko
In reply to this post by Ryan Scott
----- 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

I can't see how this doesn't require changes to Template Haskell.
In order to generate a newtype declaration via TH one must use
where last `Cxt` param is a list of instanses to be derived,
but `Cxt` is just `[Type]` and `Type` doesn't take any Pragmas.


2016-07-17 7:02 GMT+05:00 Ryan Scott <[hidden email]>:
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: deriving strategies syntax

Ben Gamari-2
In reply to this post by Oleg Grenrus
Oleg Grenrus <[hidden email]> writes:

> Should we test drive https://github.com/ghc-proposals/ghc-proposals
> <https://github.com/ghc-proposals/ghc-proposals> on this proposal?
>
I think it would be a great idea. That being said, given that it's not
be approved yet, I'm in no position to require it. Ryan, I'll leave this
call up to you. If you would like to write up a proposal using the
template in the repository then by all means let's give it a try.
If not, then no worries; we can continue here.

Cheers,

- Ben


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (482 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: deriving strategies syntax

Ryan Scott
Ben,

> I think it would be a great idea. That being said, given that it's not
> be approved yet, I'm in no position to require it. Ryan, I'll leave this
> call up to you. If you would like to write up a proposal using the
> template in the repository then by all means let's give it a try.
> If not, then no worries; we can continue here.

I hadn't thought of using ghc-proposals for this, and since it's still
in a nascent state, I'll opt to continue using the GHC devs mailing
list for this dicussion.


Alexey,

> I can't see how this doesn't require changes to Template Haskell.

You are correct, I got my wires crossed when trying to recall the
details. I think what I (sloppily) remembered was that in an earlier
revision of https://phabricator.haskell.org/D2280, I had implemented a
pragma-based approach that didn't require a language extension. But I
now consider that a mistake, so I've introduced the
-XDerivingStrategies extension, which should be required regardless of
what syntax we decide to adopt.

Ryan S.

On Sun, Jul 17, 2016 at 6:36 AM, Ben Gamari <[hidden email]> wrote:

> Oleg Grenrus <[hidden email]> writes:
>
>> Should we test drive https://github.com/ghc-proposals/ghc-proposals
>> <https://github.com/ghc-proposals/ghc-proposals> on this proposal?
>>
> I think it would be a great idea. That being said, given that it's not
> be approved yet, I'm in no position to require it. Ryan, I'll leave this
> call up to you. If you would like to write up a proposal using the
> template in the repository then by all means let's give it a try.
> If not, then no worries; we can continue here.
>
> Cheers,
>
> - Ben
>
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: deriving strategies syntax

Elliot Cameron-2

Just a quick thought: The term "built-in" seems a bit myopic IMO since all these extensions are in a sense built-in, and especially if any of them make it into Haskell 2020. I wonder if "standard" would be better or something similar.


On Jul 17, 2016 08:57, "Ryan Scott" <[hidden email]> wrote:
Ben,

> I think it would be a great idea. That being said, given that it's not
> be approved yet, I'm in no position to require it. Ryan, I'll leave this
> call up to you. If you would like to write up a proposal using the
> template in the repository then by all means let's give it a try.
> If not, then no worries; we can continue here.

I hadn't thought of using ghc-proposals for this, and since it's still
in a nascent state, I'll opt to continue using the GHC devs mailing
list for this dicussion.


Alexey,

> I can't see how this doesn't require changes to Template Haskell.

You are correct, I got my wires crossed when trying to recall the
details. I think what I (sloppily) remembered was that in an earlier
revision of https://phabricator.haskell.org/D2280, I had implemented a
pragma-based approach that didn't require a language extension. But I
now consider that a mistake, so I've introduced the
-XDerivingStrategies extension, which should be required regardless of
what syntax we decide to adopt.

Ryan S.

On Sun, Jul 17, 2016 at 6:36 AM, Ben Gamari <[hidden email]> wrote:
> Oleg Grenrus <[hidden email]> writes:
>
>> Should we test drive https://github.com/ghc-proposals/ghc-proposals
>> <https://github.com/ghc-proposals/ghc-proposals> on this proposal?
>>
> I think it would be a great idea. That being said, given that it's not
> be approved yet, I'm in no position to require it. Ryan, I'll leave this
> call up to you. If you would like to write up a proposal using the
> template in the repository then by all means let's give it a try.
> If not, then no worries; we can continue here.
>
> Cheers,
>
> - Ben
>
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: deriving strategies syntax

Ryan Scott
That's an interesting thought. I only chose "builtin" since it has a
history of being used for this purpose within GHC's internals [1].

That being said, "standard" does have its own problems, since several
of the typeclasses covered by it (Data, Generic(1), Lift, etc.) are
not part of any Haskell standard. (I don't know if that's the
connotation you aimed for, but that's what I glean from reading it.) I
want something that conveys the fact that when deriving this instance,
GHC is using some domain-specific knowledge to derive the instance.

If not "builtin" or "standard", some other possibilities I can think
of are "native", "original", or "specialized". I don't know if I have
a strong preference for one in particular.

Another suggestion previously tossed around was "default", but I
decided against that since that keyword is also used in
-XDefaultSignatures, which very much has a generic programming
connotation, and I didn't want users to confuse it with the
-XDeriveAnyClass strategy.

Ryan S.
-----
[1] http://git.haskell.org/ghc.git/blob/5df92f6776b31b375a80865e7db1f330d929c18f:/compiler/typecheck/TcGenDeriv.hs#l116

On Sun, Jul 17, 2016 at 8:59 AM, Elliot Cameron <[hidden email]> wrote:

> Just a quick thought: The term "built-in" seems a bit myopic IMO since all
> these extensions are in a sense built-in, and especially if any of them make
> it into Haskell 2020. I wonder if "standard" would be better or something
> similar.
>
>
> On Jul 17, 2016 08:57, "Ryan Scott" <[hidden email]> wrote:
>>
>> Ben,
>>
>> > I think it would be a great idea. That being said, given that it's not
>> > be approved yet, I'm in no position to require it. Ryan, I'll leave this
>> > call up to you. If you would like to write up a proposal using the
>> > template in the repository then by all means let's give it a try.
>> > If not, then no worries; we can continue here.
>>
>> I hadn't thought of using ghc-proposals for this, and since it's still
>> in a nascent state, I'll opt to continue using the GHC devs mailing
>> list for this dicussion.
>>
>>
>> Alexey,
>>
>> > I can't see how this doesn't require changes to Template Haskell.
>>
>> You are correct, I got my wires crossed when trying to recall the
>> details. I think what I (sloppily) remembered was that in an earlier
>> revision of https://phabricator.haskell.org/D2280, I had implemented a
>> pragma-based approach that didn't require a language extension. But I
>> now consider that a mistake, so I've introduced the
>> -XDerivingStrategies extension, which should be required regardless of
>> what syntax we decide to adopt.
>>
>> Ryan S.
>>
>> On Sun, Jul 17, 2016 at 6:36 AM, Ben Gamari <[hidden email]> wrote:
>> > Oleg Grenrus <[hidden email]> writes:
>> >
>> >> Should we test drive https://github.com/ghc-proposals/ghc-proposals
>> >> <https://github.com/ghc-proposals/ghc-proposals> on this proposal?
>> >>
>> > I think it would be a great idea. That being said, given that it's not
>> > be approved yet, I'm in no position to require it. Ryan, I'll leave this
>> > call up to you. If you would like to write up a proposal using the
>> > template in the repository then by all means let's give it a try.
>> > If not, then no worries; we can continue here.
>> >
>> > Cheers,
>> >
>> > - Ben
>> >
>> _______________________________________________
>> ghc-devs mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: deriving strategies syntax

Carter Schonwald
Builtin sounds fine to me personally. WiredIn would also be valid , though that  would overlap with some other ghc internals terminology.  

When the deriving strategies extension isn't enabled , what will the new semantics be when more than one strategy applies? What's our new answer there ?


On Sunday, July 17, 2016, Ryan Scott <[hidden email]> wrote:
That's an interesting thought. I only chose "builtin" since it has a
history of being used for this purpose within GHC's internals [1].

That being said, "standard" does have its own problems, since several
of the typeclasses covered by it (Data, Generic(1), Lift, etc.) are
not part of any Haskell standard. (I don't know if that's the
connotation you aimed for, but that's what I glean from reading it.) I
want something that conveys the fact that when deriving this instance,
GHC is using some domain-specific knowledge to derive the instance.

If not "builtin" or "standard", some other possibilities I can think
of are "native", "original", or "specialized". I don't know if I have
a strong preference for one in particular.

Another suggestion previously tossed around was "default", but I
decided against that since that keyword is also used in
-XDefaultSignatures, which very much has a generic programming
connotation, and I didn't want users to confuse it with the
-XDeriveAnyClass strategy.

Ryan S.
-----
[1] http://git.haskell.org/ghc.git/blob/5df92f6776b31b375a80865e7db1f330d929c18f:/compiler/typecheck/TcGenDeriv.hs#l116

On Sun, Jul 17, 2016 at 8:59 AM, Elliot Cameron <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;eacameron@gmail.com&#39;)">eacameron@...> wrote:
> Just a quick thought: The term "built-in" seems a bit myopic IMO since all
> these extensions are in a sense built-in, and especially if any of them make
> it into Haskell 2020. I wonder if "standard" would be better or something
> similar.
>
>
> On Jul 17, 2016 08:57, "Ryan Scott" <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;ryan.gl.scott@gmail.com&#39;)">ryan.gl.scott@...> wrote:
>>
>> Ben,
>>
>> > I think it would be a great idea. That being said, given that it's not
>> > be approved yet, I'm in no position to require it. Ryan, I'll leave this
>> > call up to you. If you would like to write up a proposal using the
>> > template in the repository then by all means let's give it a try.
>> > If not, then no worries; we can continue here.
>>
>> I hadn't thought of using ghc-proposals for this, and since it's still
>> in a nascent state, I'll opt to continue using the GHC devs mailing
>> list for this dicussion.
>>
>>
>> Alexey,
>>
>> > I can't see how this doesn't require changes to Template Haskell.
>>
>> You are correct, I got my wires crossed when trying to recall the
>> details. I think what I (sloppily) remembered was that in an earlier
>> revision of https://phabricator.haskell.org/D2280, I had implemented a
>> pragma-based approach that didn't require a language extension. But I
>> now consider that a mistake, so I've introduced the
>> -XDerivingStrategies extension, which should be required regardless of
>> what syntax we decide to adopt.
>>
>> Ryan S.
>>
>> On Sun, Jul 17, 2016 at 6:36 AM, Ben Gamari <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;ben@smart-cactus.org&#39;)">ben@...> wrote:
>> > Oleg Grenrus <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;oleg.grenrus@iki.fi&#39;)">oleg.grenrus@...> writes:
>> >
>> >> Should we test drive https://github.com/ghc-proposals/ghc-proposals
>> >> <https://github.com/ghc-proposals/ghc-proposals> on this proposal?
>> >>
>> > I think it would be a great idea. That being said, given that it's not
>> > be approved yet, I'm in no position to require it. Ryan, I'll leave this
>> > call up to you. If you would like to write up a proposal using the
>> > template in the repository then by all means let's give it a try.
>> > If not, then no worries; we can continue here.
>> >
>> > Cheers,
>> >
>> > - Ben
>> >
>> _______________________________________________
>> ghc-devs mailing list
>> <a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;ghc-devs@haskell.org&#39;)">ghc-devs@...
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;ghc-devs@haskell.org&#39;)">ghc-devs@...
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: deriving strategies syntax

Ryan Scott
> When the deriving strategies extension isn't enabled , what will the new semantics be when more than one strategy applies? What's our new answer there ?

GHC already has a process for resolving which strategy to pick in a
plain old deriving statement, but it isn't well documented. I've added
a section to the users' guide in [1], but I'll summarize it here.

When processing a deriving statement without an explicit strategy:

1. If the typeclass is built-in (or wired-in, as you suggested), and
any necessary language extension is enabled (e.g., -XDeriveFunctor for
Functor), then GHC will use the corresponding built-in algorithm to
derive the instance.
2. Otherwise, GHC checks if either -XGeneralizedNewtypeDeriving or
-XDeriveAnyClass are enabled, and if the class is able to be derived
with one of those approaches, GHC does so. If BOTH extensions are
enabled and the class can be derived with either approach, GHC
defaults to -XDeriveAnyClass (but also emitting a warning about the
choice it made to resolve the ambiguity).
3. Otherwise, GHC errors.

Again, this is current GHC behavior, not a new or proposed feature.

Ryan S.
-----
[1] https://phabricator.haskell.org/D2280#02e78429
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: deriving strategies syntax

Richard Eisenberg-2
In reply to this post by Ryan Scott
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 <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: deriving strategies syntax

Andres Loeh-5
In reply to this post by Ryan Scott
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 <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: deriving strategies syntax

Richard Eisenberg-2

> On Jul 18, 2016, at 2:54 AM, Andres Loeh <[hidden email]> wrote:
>
> 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".

I thought about verbosity here, and it's not clear which one is more verbose. For example, I frequently define a new newtype and then wish to use GND to derive a whole host of instances. In this case (is it common?), `deriving (X, Y) deriving newtype (A,B,C,D,E,F)` is shorter than putting newtype on each class name.

I suppose we could provide both options, but that may be one bridge too far.

Richard
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: deriving strategies syntax

Ryan Scott
Andres,

> The objects probably shouldn't be type synonyms, but
> they could be special datatypes or type families, perhaps.

I considered that - we already have some special datatypes, type
families, and type classes currently. However, neither datatypes nor
type families are allowed to appear as the outermost type in an
instance declaration (unless we bake in a very prominent exception to
this rule), and if we imbued type classes with this magic, one might
think that "deriving (GND Eq)" means we're deriving an instance for
the magical GND class, not Eq. So those approaches don't sound
satisfying to me on a cursory examination.

Richard,

> The one idea I can suggest in this space (somewhat tongue-in-cheek, but feel free to take it seriously) is `bespoke`

It might be a tongue-in-cheek suggestion, but I _really_ like it. It
captures the intended semantics better than any other previous
suggestion, I think. And we're already going to be appropriating a new
keyword with "anyclass", so why not take "bespoke" as well? :)

Please stop me if I've slipped into madness here.

> I thought about verbosity here, and it's not clear which one is more verbose. For example, I frequently define a new newtype and then wish to use GND to derive a whole host of instances. In this case (is it common?), `deriving (X, Y) deriving newtype (A,B,C,D,E,F)` is shorter than putting newtype on each class name.

That's a good point. Another thing to consider is that I suspect in
90% of the time, users are only going to be reaching for
-XDerivingStrategies in the scenario when they enable both
-XGeneralizedNewtypeDeriving and -XDeriveAnyClass. That will happen
when they want to derive instances for newtypes, and as you said, you
typically derive several instances at a time when defining newtypes.
Therefore, it seems less noisy to factor out the deriving strategy
names so that readers can tell at a glance which batch of instances
are newtype-derived and which are anyclass-derived, instead of having
to read a keyword before every single type.

Plus, on a superficial level, I like keeping the deriving strategy
name outside of the parentheses. I think it makes clear that these
keywords aren't modifying the type we're deriving, only the means by
which we're deriving it. Of course, you may feel differently than I
do, so please speak up if you disagree!


Ryan S.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: deriving strategies syntax

Richard Eisenberg-4

> On Jul 18, 2016, at 9:59 AM, Ryan Scott <[hidden email]> wrote:
>
>> The one idea I can suggest in this space (somewhat tongue-in-cheek, but feel free to take it seriously) is `bespoke`
>
> It might be a tongue-in-cheek suggestion, but I _really_ like it. It
> captures the intended semantics better than any other previous
> suggestion, I think. And we're already going to be appropriating a new
> keyword with "anyclass", so why not take "bespoke" as well? :)
>
> Please stop me if I've slipped into madness here.

We don't actually have to worry about keyword snatching, as there is no other lowercase word that can appear directly after `deriving`. We're happily in a new part of the grammar.

On "bespoke":
Pros:
 * It has precisely the right meaning
 * It's a fun word. (Fellow Americans, please update if this disagrees with your experience:) At least for Americans, for whom the word is instantly associated with spiffy haberdashery sold on Savile Row, London. It was actually quite a surprise to me when living in the UK that bespoke is used for other things as well. Example from my time there: I once went on a bespoke snowshoeing trip to France.

Cons:
 * It's a fun word. People from those other languages with their boring OOP terms already think we're strange for having monoids and monads. Not to mention profunctors. What will they think of a bespoke Functor?

I'm clearly enjoying this way too much.

>
> Plus, on a superficial level, I like keeping the deriving strategy
> name outside of the parentheses. I think it makes clear that these
> keywords aren't modifying the type we're deriving, only the means by
> which we're deriving it. Of course, you may feel differently than I
> do, so please speak up if you disagree!
 
I actually agree here. This keeps all the keywords clustered together instead of interspersed with the more interesting bits.

Richard
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: deriving strategies syntax

Andres Loeh-5
In reply to this post by Ryan Scott
> It might be a tongue-in-cheek suggestion, but I _really_ like it. It
> captures the intended semantics better than any other previous
> suggestion, I think. And we're already going to be appropriating a new
> keyword with "anyclass", so why not take "bespoke" as well? :)

It doesn't have to be a "keyword" in the sense of reservedid, right?

>> I thought about verbosity here, and it's not clear which one is more verbose. For example, I frequently define a new newtype and then wish to use GND to derive a whole host of instances. In this case (is it common?), `deriving (X, Y) deriving newtype (A,B,C,D,E,F)` is shorter than putting newtype on each class name.
>
> That's a good point. Another thing to consider is that I suspect in
> 90% of the time, users are only going to be reaching for
> -XDerivingStrategies in the scenario when they enable both
> -XGeneralizedNewtypeDeriving and -XDeriveAnyClass. That will happen
> when they want to derive instances for newtypes, and as you said, you
> typically derive several instances at a time when defining newtypes.
> Therefore, it seems less noisy to factor out the deriving strategy
> names so that readers can tell at a glance which batch of instances
> are newtype-derived and which are anyclass-derived, instead of having
> to read a keyword before every single type.

Yes, you've convinced me that putting the strategy once in front is at
least not worse.

> Plus, on a superficial level, I like keeping the deriving strategy
> name outside of the parentheses. I think it makes clear that these
> keywords aren't modifying the type we're deriving, only the means by
> which we're deriving it. Of course, you may feel differently than I
> do, so please speak up if you disagree!

The very first times when I've talked to others about this feature, I
think I've always used "deriving (Eq via bespoke, Monad via gnd)" as
syntax, but yes, in general I agree that keeping it completely out of
the parentheses may be a mild advantage.

Cheers,
  Andres
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: deriving strategies syntax

Ryan Scott
> It doesn't have to be a "keyword" in the sense of reservedid, right?

Correct, it's only a keyword when used in the context of deriving,
similar to how "role" is only a keyword in the context of "type role".
You could still define, say, `id role = role` if you so wished.

Ryan S.

On Mon, Jul 18, 2016 at 10:39 AM, Andres Loeh <[hidden email]> wrote:

>> It might be a tongue-in-cheek suggestion, but I _really_ like it. It
>> captures the intended semantics better than any other previous
>> suggestion, I think. And we're already going to be appropriating a new
>> keyword with "anyclass", so why not take "bespoke" as well? :)
>
> It doesn't have to be a "keyword" in the sense of reservedid, right?
>
>>> I thought about verbosity here, and it's not clear which one is more verbose. For example, I frequently define a new newtype and then wish to use GND to derive a whole host of instances. In this case (is it common?), `deriving (X, Y) deriving newtype (A,B,C,D,E,F)` is shorter than putting newtype on each class name.
>>
>> That's a good point. Another thing to consider is that I suspect in
>> 90% of the time, users are only going to be reaching for
>> -XDerivingStrategies in the scenario when they enable both
>> -XGeneralizedNewtypeDeriving and -XDeriveAnyClass. That will happen
>> when they want to derive instances for newtypes, and as you said, you
>> typically derive several instances at a time when defining newtypes.
>> Therefore, it seems less noisy to factor out the deriving strategy
>> names so that readers can tell at a glance which batch of instances
>> are newtype-derived and which are anyclass-derived, instead of having
>> to read a keyword before every single type.
>
> Yes, you've convinced me that putting the strategy once in front is at
> least not worse.
>
>> Plus, on a superficial level, I like keeping the deriving strategy
>> name outside of the parentheses. I think it makes clear that these
>> keywords aren't modifying the type we're deriving, only the means by
>> which we're deriving it. Of course, you may feel differently than I
>> do, so please speak up if you disagree!
>
> The very first times when I've talked to others about this feature, I
> think I've always used "deriving (Eq via bespoke, Monad via gnd)" as
> syntax, but yes, in general I agree that keeping it completely out of
> the parentheses may be a mild advantage.
>
> Cheers,
>   Andres
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Request for feedback: deriving strategies syntax

GHC - devs mailing list
In reply to this post by Ryan Scott
I'm not following all the details here, and I do not feel strongly about syntax; but I do hope that you'll update the wiki page to reflect the discussion.

Thanks

Simon

-----Original Message-----
From: ghc-devs [mailto:[hidden email]] On Behalf Of Ryan Scott
Sent: 18 July 2016 15:00
To: Richard Eisenberg <[hidden email]>
Cc: Andres Loeh <[hidden email]>; GHC developers <[hidden email]>
Subject: Re: Request for feedback: deriving strategies syntax

Andres,

> The objects probably shouldn't be type synonyms, but they could be
> special datatypes or type families, perhaps.

I considered that - we already have some special datatypes, type families, and type classes currently. However, neither datatypes nor type families are allowed to appear as the outermost type in an instance declaration (unless we bake in a very prominent exception to this rule), and if we imbued type classes with this magic, one might think that "deriving (GND Eq)" means we're deriving an instance for the magical GND class, not Eq. So those approaches don't sound satisfying to me on a cursory examination.

Richard,

> The one idea I can suggest in this space (somewhat tongue-in-cheek,
> but feel free to take it seriously) is `bespoke`

It might be a tongue-in-cheek suggestion, but I _really_ like it. It captures the intended semantics better than any other previous suggestion, I think. And we're already going to be appropriating a new keyword with "anyclass", so why not take "bespoke" as well? :)

Please stop me if I've slipped into madness here.

> I thought about verbosity here, and it's not clear which one is more verbose. For example, I frequently define a new newtype and then wish to use GND to derive a whole host of instances. In this case (is it common?), `deriving (X, Y) deriving newtype (A,B,C,D,E,F)` is shorter than putting newtype on each class name.

That's a good point. Another thing to consider is that I suspect in 90% of the time, users are only going to be reaching for -XDerivingStrategies in the scenario when they enable both -XGeneralizedNewtypeDeriving and -XDeriveAnyClass. That will happen when they want to derive instances for newtypes, and as you said, you typically derive several instances at a time when defining newtypes.
Therefore, it seems less noisy to factor out the deriving strategy names so that readers can tell at a glance which batch of instances are newtype-derived and which are anyclass-derived, instead of having to read a keyword before every single type.

Plus, on a superficial level, I like keeping the deriving strategy name outside of the parentheses. I think it makes clear that these keywords aren't modifying the type we're deriving, only the means by which we're deriving it. Of course, you may feel differently than I do, so please speak up if you disagree!


Ryan S.
_______________________________________________
ghc-devs mailing list
[hidden email]
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cea562a7e9e494f07cede08d3af13cbc7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=rKTWOkEZsKUdDOTnk7WL2BNx1lf36uelef4JDg0pX44%3d
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: deriving strategies syntax

Ryan Scott
Thanks for the feedback, everyone! I've typed up the developments so
far in the DerivingStrategies Haskell wiki page [1].

Here's what seems to be the consensus:

* The syntax in which actual keywords are used to designate deriving
strategies was the clear favorite.
* In particular, a slight edge goes to the form in which multiple
deriving clauses can be placed after a datatype, and each `deriving`
clause has its own (optional) strategy keyword, as opposed to putting
the keyword directly in front of the derived type.
* The `builtin` keyword was poorly received. There isn't a obvious
candidate to replace it, and several of us like the word `bespoke`, so
it looks like `bespoke` will be the replacement. (If someone ends up
complaining about it, we've got several other choices.)


Any other questions or comments?

Ryan S.
-----
[1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategies

On Mon, Jul 18, 2016 at 5:54 PM, Simon Peyton Jones
<[hidden email]> wrote:

> I'm not following all the details here, and I do not feel strongly about syntax; but I do hope that you'll update the wiki page to reflect the discussion.
>
> Thanks
>
> Simon
>
> -----Original Message-----
> From: ghc-devs [mailto:[hidden email]] On Behalf Of Ryan Scott
> Sent: 18 July 2016 15:00
> To: Richard Eisenberg <[hidden email]>
> Cc: Andres Loeh <[hidden email]>; GHC developers <[hidden email]>
> Subject: Re: Request for feedback: deriving strategies syntax
>
> Andres,
>
>> The objects probably shouldn't be type synonyms, but they could be
>> special datatypes or type families, perhaps.
>
> I considered that - we already have some special datatypes, type families, and type classes currently. However, neither datatypes nor type families are allowed to appear as the outermost type in an instance declaration (unless we bake in a very prominent exception to this rule), and if we imbued type classes with this magic, one might think that "deriving (GND Eq)" means we're deriving an instance for the magical GND class, not Eq. So those approaches don't sound satisfying to me on a cursory examination.
>
> Richard,
>
>> The one idea I can suggest in this space (somewhat tongue-in-cheek,
>> but feel free to take it seriously) is `bespoke`
>
> It might be a tongue-in-cheek suggestion, but I _really_ like it. It captures the intended semantics better than any other previous suggestion, I think. And we're already going to be appropriating a new keyword with "anyclass", so why not take "bespoke" as well? :)
>
> Please stop me if I've slipped into madness here.
>
>> I thought about verbosity here, and it's not clear which one is more verbose. For example, I frequently define a new newtype and then wish to use GND to derive a whole host of instances. In this case (is it common?), `deriving (X, Y) deriving newtype (A,B,C,D,E,F)` is shorter than putting newtype on each class name.
>
> That's a good point. Another thing to consider is that I suspect in 90% of the time, users are only going to be reaching for -XDerivingStrategies in the scenario when they enable both -XGeneralizedNewtypeDeriving and -XDeriveAnyClass. That will happen when they want to derive instances for newtypes, and as you said, you typically derive several instances at a time when defining newtypes.
> Therefore, it seems less noisy to factor out the deriving strategy names so that readers can tell at a glance which batch of instances are newtype-derived and which are anyclass-derived, instead of having to read a keyword before every single type.
>
> Plus, on a superficial level, I like keeping the deriving strategy name outside of the parentheses. I think it makes clear that these keywords aren't modifying the type we're deriving, only the means by which we're deriving it. Of course, you may feel differently than I do, so please speak up if you disagree!
>
>
> Ryan S.
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cea562a7e9e494f07cede08d3af13cbc7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=rKTWOkEZsKUdDOTnk7WL2BNx1lf36uelef4JDg0pX44%3d
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback: deriving strategies syntax

Ryan Scott
That is a good question. Weirdly enough, the current behavior for how
a deriving strategy is resolved (without explicit keywords) isn't
really documented anywhere, so I attempted to figure out what GHC
currently does and documented it here [1]. I'll reproduce the
algorithm (including deriving strategies) below:

1. Look for a deriving strategy. If one is present, use that.

2. (a) If deriving an `Eq`, `Ord`, `Ix`, or `Bounded` instance for a
newtype, use the `GeneralizedNewtypeDeriving` strategy (even if the
language extension isn't enabled).

   (b) If deriving a `Read`, `Show`, `Data`, `Generic`, `Generic1`,
`Typeable`, `Traversable`, or `Lift` instance for a newtype, go to
step 3.

   (c) Otherwise, if deriving a "standard derivable class" (e.g.,
`Eq`, `Ord`, `Generic`, etc.) instance for a newtype, and
`-XGeneralizedNewtypeDeriving` is enabled, derive the class using the
`GeneralizedNewtypeDeriving` strategy.

   (d) Otherwise, if deriving an instance for a newtype and both
`-XGeneralizedNewtypeDeriving` and `-XDeriveAnyClass` are enabled,
default to `DeriveAnyClass`, but emit a warning stating the ambiguity.

   (e) Otherwise, if deriving an instance for a newtype, the datatype
and typeclass can be successfully used with
`GeneralizedNewtypeDeriving`, and `-XGeneralizedNewtypeDeriving` is
enabled, do so.

3. (a) If deriving a "standard derivable class" (e.g., `Eq`, `Ord`,
`Generic`, etc.) and the corresponding language extension is enabled
(if necessary), do so. If the language extension is not enabled, throw
an error.

   (b) Otherwise, if `-XDeriveAnyClass` is enabled, use that.

   (c) Otherwise, throw an error.

This is quite ugly, but to my knowledge this is currently what GHC
does (excluding 2(c), which is a bit that fixes a bug reported in Trac
#10598 [2]), so there shouldn't be any change in behavior from before.
This is another good reason to want deriving strategies: trying to
remember all of that is nearly impossible!

Ryan S.
-----
[1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategies#Thederivingstrategyresolutionalgorithm
[2] https://ghc.haskell.org/trac/ghc/ticket/10598

On Wed, Aug 3, 2016 at 11:53 AM, Richard Eisenberg <[hidden email]> wrote:
>
>> On Aug 2, 2016, at 6:59 PM, Ryan Scott <[hidden email]> wrote:
>> Any other questions or comments?
>>
>
> Yes, a question: What is the behavior if no keyword is given? Any change here from the status quo is quite dangerous from a backward-compatibility standpoint, but I wonder if we could start issuing warnings/errors in a few years.
>
> Richard
>
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
1234