Re: Request for feedback: deriving strategies syntax

Ryan Scott

25 Aug 2016 25 Aug '16

3:49 p.m.

Hello, everyone! Sorry for not being able to respond to some of the recent feedback. Well, it seems I'm at a bit of an impasse again. I originally changed "builtin" to "bespoke" because enough GHC devs voiced their displeasure (ranging from moderate to severe) with "builtin". I hoped that choosing "bespoke" would strike a happy medium where we could have a term that (1) reasonably describes its intended purpose, (2) wouldn't be highly misleading upon an initial glance, and (3) wouldn't be too off-putting to use as a reserved keyword. Unfortunately, I over-estimated how well "bespoke" meets criterion 3, since several people have _also_ voiced their displeasure with it! (Again, ranging from moderate to severe.) So we're back to square one, it seems. I don't want to push this patch without a general feeling of community consensus, but the patch is complete after all, with the exception of bikeshedding, so I'd like to try and come up with a colo(u)r that folks will be happy with so we can proceed and I can work on other things that need this feature. So, instead of "builtin" and "bespoke", I propose reconsidering an earlier suggestion of Elliot Cameron's: "standard". I had previously expressed reservations about "standard" before, since I felt it might be miscontrued as meaning "a Haskell standard" (e.g., the Haskell Report). But upon further thought, I have actually come to like the word "standard". Here's why: 1. It's simple. "Standard" is recognizable whether you speak American English, British English, or pretty much any other variant that I'm aware of. 2. It has precedent. A GHC error message already uses the phrase "standard derivable classes" to refer to Eq, Ord, Functor, etc. If we adopt "standard" as our keyword, then we could endow this phrase with a more precise meaning. 3. It reflects history. This deriving strategy (that I'm proposing to name "standard") was the very first deriving strategy that GHC supported (to my knowledge), so it makes sense to refer to this strategy as the "standard" one, since all other strategies were added later. 4. It's not too ambiguous. As opposed to say, "default" (which could be confused with -XDefaultSignatures, i.e., the anyclass strategy), I think that "standard" has a pretty obvious connotation in the context of deriving. There is the possibility of misinterpreting "standard" to refer to the Haskell Report, but that wouldn't be the worst misconception in the world to make, since several "standard derivable classes" are actually in the Haskell Report (whereas neither GeneralizedNewtypeDeriving nor DeriveAnyClass are). What does everyone think? Ryan S.

Show replies by date

Ryan Scott

27 Sep 27 Sep

7:13 p.m.

New subject: Request for feedback: deriving strategies syntax

Sorry to keep changing my mind on this topic, but I'd like to make one last alternate suggestion, which I think surpasses all the previous ones. Joachim proposed that what was called "bespoke", "standard", or "builtin" in the past be called "stock" instead [1]. I like this idea since: 1. "Stock" is a short, instantly recognizable English word, no matter where you live (I think). 2. It conveys the right meaning, as "stock" indicates something straightforward or normal (in contrast to GND and DAC, which do something a bit more novel). "Stock" has other meanings, but in this context I believe it's clear what it indicates. 3. It doesn't have the disadvantages of the other suggestions. Besides the points already covered, Joachim noted that "bespoke" has connotations of giving instances that would be tailor-fit for a datatype (e.g., "ignore field x in the Eq instance, because it is just a cached value that depends on the other"), when in reality, the strategy is far more mechanical than that! Thoughts? Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/10598?replyto=50#comment:50 On Fri, Aug 26, 2016 at 4:49 AM, Ryan Scott wrote:

...

Hello, everyone! Sorry for not being able to respond to some of the recent feedback.

Well, it seems I'm at a bit of an impasse again. I originally changed "builtin" to "bespoke" because enough GHC devs voiced their displeasure (ranging from moderate to severe) with "builtin". I hoped that choosing "bespoke" would strike a happy medium where we could have a term that (1) reasonably describes its intended purpose, (2) wouldn't be highly misleading upon an initial glance, and (3) wouldn't be too off-putting to use as a reserved keyword.

Unfortunately, I over-estimated how well "bespoke" meets criterion 3, since several people have _also_ voiced their displeasure with it! (Again, ranging from moderate to severe.) So we're back to square one, it seems. I don't want to push this patch without a general feeling of community consensus, but the patch is complete after all, with the exception of bikeshedding, so I'd like to try and come up with a colo(u)r that folks will be happy with so we can proceed and I can work on other things that need this feature.

So, instead of "builtin" and "bespoke", I propose reconsidering an earlier suggestion of Elliot Cameron's: "standard". I had previously expressed reservations about "standard" before, since I felt it might be miscontrued as meaning "a Haskell standard" (e.g., the Haskell Report). But upon further thought, I have actually come to like the word "standard". Here's why:

1. It's simple. "Standard" is recognizable whether you speak American English, British English, or pretty much any other variant that I'm aware of. 2. It has precedent. A GHC error message already uses the phrase "standard derivable classes" to refer to Eq, Ord, Functor, etc. If we adopt "standard" as our keyword, then we could endow this phrase with a more precise meaning. 3. It reflects history. This deriving strategy (that I'm proposing to name "standard") was the very first deriving strategy that GHC supported (to my knowledge), so it makes sense to refer to this strategy as the "standard" one, since all other strategies were added later. 4. It's not too ambiguous. As opposed to say, "default" (which could be confused with -XDefaultSignatures, i.e., the anyclass strategy), I think that "standard" has a pretty obvious connotation in the context of deriving. There is the possibility of misinterpreting "standard" to refer to the Haskell Report, but that wouldn't be the worst misconception in the world to make, since several "standard derivable classes" are actually in the Haskell Report (whereas neither GeneralizedNewtypeDeriving nor DeriveAnyClass are).

What does everyone think?

Ryan S.

Carter Schonwald

7:49 p.m.

New subject: Request for feedback: deriving strategies syntax

This wouldn't eat up Stock as a data type or type classes or stock in any other syntactic context right? While this term in the finance context hasn't come up in my own work this past year, just want to make sure it won't eat a key word piece of name space in value or types land Otherwise : standard or stock all sound good to me. On Sep 27, 2016 7:14 PM, "Ryan Scott" wrote:

...

Sorry to keep changing my mind on this topic, but I'd like to make one last alternate suggestion, which I think surpasses all the previous ones. Joachim proposed that what was called "bespoke", "standard", or "builtin" in the past be called "stock" instead [1]. I like this idea since:

1. "Stock" is a short, instantly recognizable English word, no matter where you live (I think). 2. It conveys the right meaning, as "stock" indicates something straightforward or normal (in contrast to GND and DAC, which do something a bit more novel). "Stock" has other meanings, but in this context I believe it's clear what it indicates. 3. It doesn't have the disadvantages of the other suggestions. Besides the points already covered, Joachim noted that "bespoke" has connotations of giving instances that would be tailor-fit for a datatype (e.g., "ignore field x in the Eq instance, because it is just a cached value that depends on the other"), when in reality, the strategy is far more mechanical than that!

Thoughts?

Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/10598?replyto=50#comment:50

On Fri, Aug 26, 2016 at 4:49 AM, Ryan Scott wrote:

...
Hello, everyone! Sorry for not being able to respond to some of the recent feedback.

Well, it seems I'm at a bit of an impasse again. I originally changed "builtin" to "bespoke" because enough GHC devs voiced their displeasure (ranging from moderate to severe) with "builtin". I hoped that choosing "bespoke" would strike a happy medium where we could have a term that (1) reasonably describes its intended purpose, (2) wouldn't be highly misleading upon an initial glance, and (3) wouldn't be too off-putting to use as a reserved keyword.

Unfortunately, I over-estimated how well "bespoke" meets criterion 3, since several people have _also_ voiced their displeasure with it! (Again, ranging from moderate to severe.) So we're back to square one, it seems. I don't want to push this patch without a general feeling of community consensus, but the patch is complete after all, with the exception of bikeshedding, so I'd like to try and come up with a colo(u)r that folks will be happy with so we can proceed and I can work on other things that need this feature.

So, instead of "builtin" and "bespoke", I propose reconsidering an earlier suggestion of Elliot Cameron's: "standard". I had previously expressed reservations about "standard" before, since I felt it might be miscontrued as meaning "a Haskell standard" (e.g., the Haskell Report). But upon further thought, I have actually come to like the word "standard". Here's why:

1. It's simple. "Standard" is recognizable whether you speak American English, British English, or pretty much any other variant that I'm aware of. 2. It has precedent. A GHC error message already uses the phrase "standard derivable classes" to refer to Eq, Ord, Functor, etc. If we adopt "standard" as our keyword, then we could endow this phrase with a more precise meaning. 3. It reflects history. This deriving strategy (that I'm proposing to name "standard") was the very first deriving strategy that GHC supported (to my knowledge), so it makes sense to refer to this strategy as the "standard" one, since all other strategies were added later. 4. It's not too ambiguous. As opposed to say, "default" (which could be confused with -XDefaultSignatures, i.e., the anyclass strategy), I think that "standard" has a pretty obvious connotation in the context of deriving. There is the possibility of misinterpreting "standard" to refer to the Haskell Report, but that wouldn't be the worst misconception in the world to make, since several "standard derivable classes" are actually in the Haskell Report (whereas neither GeneralizedNewtypeDeriving nor DeriveAnyClass are).

What does everyone think?

Ryan S.

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Ryan Scott

7:55 p.m.

New subject: Request for feedback: deriving strategies syntax

...

This wouldn't eat up Stock as a data type or type classes or stock in any other syntactic context right?

A valid concern! Rest assured, you'd still be able to use "stock" as, say, a variable in a function, since GHC's parser has a production just for IDs that have meanings in special contexts. (If you want to win at Haskell trivia night, the current special IDs are "as", "qualified", "hiding", "export", "label", "dynamic", "stdcall", "ccall", "capi", "prim", "javascript", and "group" [1]). In my implementation, I make "stock" and "anyclass" special IDs, so they only become keywords when used after "deriving". Ryan S. ----- [1] http://git.haskell.org/ghc.git/blob/f897b7427a4804e3285144f57676574d338be1f5... [2] On Wed, Sep 28, 2016 at 8:49 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

This wouldn't eat up Stock as a data type or type classes or stock in any other syntactic context right?

While this term in the finance context hasn't come up in my own work this past year, just want to make sure it won't eat a key word piece of name space in value or types land

Otherwise : standard or stock all sound good to me.

On Sep 27, 2016 7:14 PM, "Ryan Scott" wrote:

...
Sorry to keep changing my mind on this topic, but I'd like to make one last alternate suggestion, which I think surpasses all the previous ones. Joachim proposed that what was called "bespoke", "standard", or "builtin" in the past be called "stock" instead [1]. I like this idea since:

1. "Stock" is a short, instantly recognizable English word, no matter where you live (I think). 2. It conveys the right meaning, as "stock" indicates something straightforward or normal (in contrast to GND and DAC, which do something a bit more novel). "Stock" has other meanings, but in this context I believe it's clear what it indicates. 3. It doesn't have the disadvantages of the other suggestions. Besides the points already covered, Joachim noted that "bespoke" has connotations of giving instances that would be tailor-fit for a datatype (e.g., "ignore field x in the Eq instance, because it is just a cached value that depends on the other"), when in reality, the strategy is far more mechanical than that!

Thoughts?

Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/10598?replyto=50#comment:50

On Fri, Aug 26, 2016 at 4:49 AM, Ryan Scott wrote:

...
Hello, everyone! Sorry for not being able to respond to some of the recent feedback.

Well, it seems I'm at a bit of an impasse again. I originally changed "builtin" to "bespoke" because enough GHC devs voiced their displeasure (ranging from moderate to severe) with "builtin". I hoped that choosing "bespoke" would strike a happy medium where we could have a term that (1) reasonably describes its intended purpose, (2) wouldn't be highly misleading upon an initial glance, and (3) wouldn't be too off-putting to use as a reserved keyword.

Unfortunately, I over-estimated how well "bespoke" meets criterion 3, since several people have _also_ voiced their displeasure with it! (Again, ranging from moderate to severe.) So we're back to square one, it seems. I don't want to push this patch without a general feeling of community consensus, but the patch is complete after all, with the exception of bikeshedding, so I'd like to try and come up with a colo(u)r that folks will be happy with so we can proceed and I can work on other things that need this feature.

So, instead of "builtin" and "bespoke", I propose reconsidering an earlier suggestion of Elliot Cameron's: "standard". I had previously expressed reservations about "standard" before, since I felt it might be miscontrued as meaning "a Haskell standard" (e.g., the Haskell Report). But upon further thought, I have actually come to like the word "standard". Here's why:

1. It's simple. "Standard" is recognizable whether you speak American English, British English, or pretty much any other variant that I'm aware of. 2. It has precedent. A GHC error message already uses the phrase "standard derivable classes" to refer to Eq, Ord, Functor, etc. If we adopt "standard" as our keyword, then we could endow this phrase with a more precise meaning. 3. It reflects history. This deriving strategy (that I'm proposing to name "standard") was the very first deriving strategy that GHC supported (to my knowledge), so it makes sense to refer to this strategy as the "standard" one, since all other strategies were added later. 4. It's not too ambiguous. As opposed to say, "default" (which could be confused with -XDefaultSignatures, i.e., the anyclass strategy), I think that "standard" has a pretty obvious connotation in the context of deriving. There is the possibility of misinterpreting "standard" to refer to the Haskell Report, but that wouldn't be the worst misconception in the world to make, since several "standard derivable classes" are actually in the Haskell Report (whereas neither GeneralizedNewtypeDeriving nor DeriveAnyClass are).

What does everyone think?

Ryan S.

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Richard Eisenberg

10:06 p.m.

New subject: Request for feedback: deriving strategies syntax

+1 on `stock` from me. Though I was all excited to get my class next semester jazzed for PL work by explaining that I had slipped a new keyword `bespoke` into a language. :) Richard

...

On Sep 27, 2016, at 7:55 PM, Ryan Scott wrote:

...
This wouldn't eat up Stock as a data type or type classes or stock in any other syntactic context right?

A valid concern! Rest assured, you'd still be able to use "stock" as, say, a variable in a function, since GHC's parser has a production just for IDs that have meanings in special contexts. (If you want to win at Haskell trivia night, the current special IDs are "as", "qualified", "hiding", "export", "label", "dynamic", "stdcall", "ccall", "capi", "prim", "javascript", and "group" [1]). In my implementation, I make "stock" and "anyclass" special IDs, so they only become keywords when used after "deriving".

Ryan S. ----- [1] http://git.haskell.org/ghc.git/blob/f897b7427a4804e3285144f57676574d338be1f5... http://git.haskell.org/ghc.git/blob/f897b7427a4804e3285144f57676574d338be1f5... [2]

On Wed, Sep 28, 2016 at 8:49 AM, Carter Schonwald mailto:carter.schonwald@gmail.com> wrote: This wouldn't eat up Stock as a data type or type classes or stock in any other syntactic context right?

While this term in the finance context hasn't come up in my own work this past year, just want to make sure it won't eat a key word piece of name space in value or types land

Otherwise : standard or stock all sound good to me.

On Sep 27, 2016 7:14 PM, "Ryan Scott" mailto:ryan.gl.scott@gmail.com> wrote: Sorry to keep changing my mind on this topic, but I'd like to make one last alternate suggestion, which I think surpasses all the previous ones. Joachim proposed that what was called "bespoke", "standard", or "builtin" in the past be called "stock" instead [1]. I like this idea since:

1. "Stock" is a short, instantly recognizable English word, no matter where you live (I think). 2. It conveys the right meaning, as "stock" indicates something straightforward or normal (in contrast to GND and DAC, which do something a bit more novel). "Stock" has other meanings, but in this context I believe it's clear what it indicates. 3. It doesn't have the disadvantages of the other suggestions. Besides the points already covered, Joachim noted that "bespoke" has connotations of giving instances that would be tailor-fit for a datatype (e.g., "ignore field x in the Eq instance, because it is just a cached value that depends on the other"), when in reality, the strategy is far more mechanical than that!

Thoughts?

Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/10598?replyto=50#comment:50 https://ghc.haskell.org/trac/ghc/ticket/10598?replyto=50#comment:50

On Fri, Aug 26, 2016 at 4:49 AM, Ryan Scott mailto:ryan.gl.scott@gmail.com> wrote: Hello, everyone! Sorry for not being able to respond to some of the recent feedback.

Well, it seems I'm at a bit of an impasse again. I originally changed "builtin" to "bespoke" because enough GHC devs voiced their displeasure (ranging from moderate to severe) with "builtin". I hoped that choosing "bespoke" would strike a happy medium where we could have a term that (1) reasonably describes its intended purpose, (2) wouldn't be highly misleading upon an initial glance, and (3) wouldn't be too off-putting to use as a reserved keyword.

Unfortunately, I over-estimated how well "bespoke" meets criterion 3, since several people have _also_ voiced their displeasure with it! (Again, ranging from moderate to severe.) So we're back to square one, it seems. I don't want to push this patch without a general feeling of community consensus, but the patch is complete after all, with the exception of bikeshedding, so I'd like to try and come up with a colo(u)r that folks will be happy with so we can proceed and I can work on other things that need this feature.

So, instead of "builtin" and "bespoke", I propose reconsidering an earlier suggestion of Elliot Cameron's: "standard". I had previously expressed reservations about "standard" before, since I felt it might be miscontrued as meaning "a Haskell standard" (e.g., the Haskell Report). But upon further thought, I have actually come to like the word "standard". Here's why:

1. It's simple. "Standard" is recognizable whether you speak American English, British English, or pretty much any other variant that I'm aware of. 2. It has precedent. A GHC error message already uses the phrase "standard derivable classes" to refer to Eq, Ord, Functor, etc. If we adopt "standard" as our keyword, then we could endow this phrase with a more precise meaning. 3. It reflects history. This deriving strategy (that I'm proposing to name "standard") was the very first deriving strategy that GHC supported (to my knowledge), so it makes sense to refer to this strategy as the "standard" one, since all other strategies were added later. 4. It's not too ambiguous. As opposed to say, "default" (which could be confused with -XDefaultSignatures, i.e., the anyclass strategy), I think that "standard" has a pretty obvious connotation in the context of deriving. There is the possibility of misinterpreting "standard" to refer to the Haskell Report, but that wouldn't be the worst misconception in the world to make, since several "standard derivable classes" are actually in the Haskell Report (whereas neither GeneralizedNewtypeDeriving nor DeriveAnyClass are).

What does everyone think?

Ryan S.

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

Elliot Cameron

11:37 p.m.

New subject: Request for feedback: deriving strategies syntax

With the "stock option" might I also suggest "OEM"? ;) +1 stock On Tue, Sep 27, 2016 at 10:06 PM, Richard Eisenberg wrote:

...

+1 on `stock` from me. Though I was all excited to get my class next semester jazzed for PL work by explaining that I had slipped a new keyword `bespoke` into a language. :)

Richard

On Sep 27, 2016, at 7:55 PM, Ryan Scott wrote:

...
This wouldn't eat up Stock as a data type or type classes or stock in any other syntactic context right?

A valid concern! Rest assured, you'd still be able to use "stock" as, say, a variable in a function, since GHC's parser has a production just for IDs that have meanings in special contexts. (If you want to win at Haskell trivia night, the current special IDs are "as", "qualified", "hiding", "export", "label", "dynamic", "stdcall", "ccall", "capi", "prim", "javascript", and "group" [1]). In my implementation, I make "stock" and "anyclass" special IDs, so they only become keywords when used after "deriving".

Ryan S. ----- [1] http://git.haskell.org/ghc.git/blob/f897b7427a4804e3285144f5767657 4d338be1f5:/compiler/parser/Parser.y#l3054 [2]

On Wed, Sep 28, 2016 at 8:49 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

...
This wouldn't eat up Stock as a data type or type classes or stock in any other syntactic context right?

While this term in the finance context hasn't come up in my own work this past year, just want to make sure it won't eat a key word piece of name space in value or types land

Otherwise : standard or stock all sound good to me.

On Sep 27, 2016 7:14 PM, "Ryan Scott" wrote:

...
Sorry to keep changing my mind on this topic, but I'd like to make one last alternate suggestion, which I think surpasses all the previous ones. Joachim proposed that what was called "bespoke", "standard", or "builtin" in the past be called "stock" instead [1]. I like this idea since:

1. "Stock" is a short, instantly recognizable English word, no matter where you live (I think). 2. It conveys the right meaning, as "stock" indicates something straightforward or normal (in contrast to GND and DAC, which do something a bit more novel). "Stock" has other meanings, but in this context I believe it's clear what it indicates. 3. It doesn't have the disadvantages of the other suggestions. Besides the points already covered, Joachim noted that "bespoke" has connotations of giving instances that would be tailor-fit for a datatype (e.g., "ignore field x in the Eq instance, because it is just a cached value that depends on the other"), when in reality, the strategy is far more mechanical than that!

Thoughts?

Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/10598?replyto=50#comment:50

On Fri, Aug 26, 2016 at 4:49 AM, Ryan Scott wrote:

...
Hello, everyone! Sorry for not being able to respond to some of the recent feedback.

Well, it seems I'm at a bit of an impasse again. I originally changed "builtin" to "bespoke" because enough GHC devs voiced their displeasure (ranging from moderate to severe) with "builtin". I hoped that choosing "bespoke" would strike a happy medium where we could have a term that (1) reasonably describes its intended purpose, (2) wouldn't be highly misleading upon an initial glance, and (3) wouldn't be too off-putting to use as a reserved keyword.

Unfortunately, I over-estimated how well "bespoke" meets criterion 3, since several people have _also_ voiced their displeasure with it! (Again, ranging from moderate to severe.) So we're back to square one, it seems. I don't want to push this patch without a general feeling of community consensus, but the patch is complete after all, with the exception of bikeshedding, so I'd like to try and come up with a colo(u)r that folks will be happy with so we can proceed and I can work on other things that need this feature.

So, instead of "builtin" and "bespoke", I propose reconsidering an earlier suggestion of Elliot Cameron's: "standard". I had previously expressed reservations about "standard" before, since I felt it might be miscontrued as meaning "a Haskell standard" (e.g., the Haskell Report). But upon further thought, I have actually come to like the word "standard". Here's why:

1. It's simple. "Standard" is recognizable whether you speak American English, British English, or pretty much any other variant that I'm aware of. 2. It has precedent. A GHC error message already uses the phrase "standard derivable classes" to refer to Eq, Ord, Functor, etc. If we adopt "standard" as our keyword, then we could endow this phrase with a more precise meaning. 3. It reflects history. This deriving strategy (that I'm proposing to name "standard") was the very first deriving strategy that GHC supported (to my knowledge), so it makes sense to refer to this strategy as the "standard" one, since all other strategies were added later. 4. It's not too ambiguous. As opposed to say, "default" (which could be confused with -XDefaultSignatures, i.e., the anyclass strategy), I think that "standard" has a pretty obvious connotation in the context of deriving. There is the possibility of misinterpreting "standard" to refer to the Haskell Report, but that wouldn't be the worst misconception in the world to make, since several "standard derivable classes" are actually in the Haskell Report (whereas neither GeneralizedNewtypeDeriving nor DeriveAnyClass are).

What does everyone think?

Ryan S.

_______________________________________________ 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

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

MarLinn

28 Sep 28 Sep

2:08 a.m.

New subject: Request for feedback: deriving strategies syntax

On 2016-09-28 04:06, Richard Eisenberg wrote:

...

+1 on `stock` from me. Though I was all excited to get my class next semester jazzed for PL work by explaining that I had slipped a new keyword `bespoke` into a language. :)

Maybe there's still a spot you can slip it in, e.g. bespoke error messages. ;) I agree that "stock" is an acceptable alternative. MarLinn

Simon Peyton Jones

8:32 a.m.

New subject: Request for feedback: deriving strategies syntax

Fine with me! Simon From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Ryan Scott Sent: 28 September 2016 00:13 To: GHC developers Subject: Re: Request for feedback: deriving strategies syntax Sorry to keep changing my mind on this topic, but I'd like to make one last alternate suggestion, which I think surpasses all the previous ones. Joachim proposed that what was called "bespoke", "standard", or "builtin" in the past be called "stock" instead [1]. I like this idea since: 1. "Stock" is a short, instantly recognizable English word, no matter where you live (I think). 2. It conveys the right meaning, as "stock" indicates something straightforward or normal (in contrast to GND and DAC, which do something a bit more novel). "Stock" has other meanings, but in this context I believe it's clear what it indicates. 3. It doesn't have the disadvantages of the other suggestions. Besides the points already covered, Joachim noted that "bespoke" has connotations of giving instances that would be tailor-fit for a datatype (e.g., "ignore field x in the Eq instance, because it is just a cached value that depends on the other"), when in reality, the strategy is far more mechanical than that! Thoughts? Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/10598?replyto=50#comment:50 On Fri, Aug 26, 2016 at 4:49 AM, Ryan Scott mailto:ryan.gl.scott@gmail.com> wrote: Hello, everyone! Sorry for not being able to respond to some of the recent feedback. Well, it seems I'm at a bit of an impasse again. I originally changed "builtin" to "bespoke" because enough GHC devs voiced their displeasure (ranging from moderate to severe) with "builtin". I hoped that choosing "bespoke" would strike a happy medium where we could have a term that (1) reasonably describes its intended purpose, (2) wouldn't be highly misleading upon an initial glance, and (3) wouldn't be too off-putting to use as a reserved keyword. Unfortunately, I over-estimated how well "bespoke" meets criterion 3, since several people have _also_ voiced their displeasure with it! (Again, ranging from moderate to severe.) So we're back to square one, it seems. I don't want to push this patch without a general feeling of community consensus, but the patch is complete after all, with the exception of bikeshedding, so I'd like to try and come up with a colo(u)r that folks will be happy with so we can proceed and I can work on other things that need this feature. So, instead of "builtin" and "bespoke", I propose reconsidering an earlier suggestion of Elliot Cameron's: "standard". I had previously expressed reservations about "standard" before, since I felt it might be miscontrued as meaning "a Haskell standard" (e.g., the Haskell Report). But upon further thought, I have actually come to like the word "standard". Here's why: 1. It's simple. "Standard" is recognizable whether you speak American English, British English, or pretty much any other variant that I'm aware of. 2. It has precedent. A GHC error message already uses the phrase "standard derivable classes" to refer to Eq, Ord, Functor, etc. If we adopt "standard" as our keyword, then we could endow this phrase with a more precise meaning. 3. It reflects history. This deriving strategy (that I'm proposing to name "standard") was the very first deriving strategy that GHC supported (to my knowledge), so it makes sense to refer to this strategy as the "standard" one, since all other strategies were added later. 4. It's not too ambiguous. As opposed to say, "default" (which could be confused with -XDefaultSignatures, i.e., the anyclass strategy), I think that "standard" has a pretty obvious connotation in the context of deriving. There is the possibility of misinterpreting "standard" to refer to the Haskell Report, but that wouldn't be the worst misconception in the world to make, since several "standard derivable classes" are actually in the Haskell Report (whereas neither GeneralizedNewtypeDeriving nor DeriveAnyClass are). What does everyone think? Ryan S.

3156

Age (days ago)

3190

Last active (days ago)

List overview

Download

7 comments

6 participants

participants (6)

Carter Schonwald
Elliot Cameron
MarLinn
Richard Eisenberg
Ryan Scott
Simon Peyton Jones