Re: Request for feedback: deriving strategies syntax

[MarLinn via ghc-devs]

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

Re: Request for feedback: deriving strategies syntax

[Elliot Cameron]

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.schonw...@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 

Re: Request for feedback: deriving strategies syntax

[Ryan Scott]

> 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:/compiler/parser/Parser.y#l3054
[2]

On Wed, Sep 28, 2016 at 8:49 AM, Carter Schonwald <
carter.schonw...@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 

Re: Request for feedback: deriving strategies syntax

[Carter Schonwald]

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

Re: Request for feedback: deriving strategies syntax

[Ryan Scott]

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

Re: Request for feedback: deriving strategies syntax

[Ryan Scott]

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

Re: Request for feedback: deriving strategies syntax

[Carter Schonwald]

Artisanal often means the same thing as bespoke in American English, though
some times with an ironic / mocking subtext. At the same time, artisanal is
often used with words like organic or natural. Which are often used in
opposition to terms like synthetic or synthesized.

In this context, it's even worse :)
It is perfectly understandable for me to say


"" I am using the built in ghc deriving machinery to synthesize the code
for the natural functor definition of this data type ""

I suppose it's bespoke in the sense that it's manufactured at most once,
it's organic / natural in that there's usually only one accepted definition
of the instance that is expected , and synthesized in that it's being
manufactured by code rather than humans (yet not synthetic in that ghc
comes with those particular derivation tactics, in contrast to user/library
supplied codes)

On Friday, August 19, 2016, Bardur Arantsson  wrote:

> (Sorry if anybody receives this twice, I think I flubbed my 'send'.)
>
> On 2016-08-19 08:34, monkleyon--- via ghc-devs wrote:
> > Yet my vote is with "bespoke". Short, informative, recognizable, and a
> > nice balance of quirky and reasonable, just like so much else here.
> >
>
> ... oh, and might I submit the opinion that quirky is not a quality that
> to be desired of a programming language, even if it's only a keyword?
>
> (Anyway, I think I'll stop here. This is too much opinion for any
> further discussion to be useful.)
>
> Regards,
>
>
> ___
> 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

Re: Request for feedback: deriving strategies syntax

[Bardur Arantsson]

(Sorry if anybody receives this twice, I think I flubbed my 'send'.)

On 2016-08-19 08:34, monkleyon--- via ghc-devs wrote:
> Yet my vote is with "bespoke". Short, informative, recognizable, and a
> nice balance of quirky and reasonable, just like so much else here.
> 

... oh, and might I submit the opinion that quirky is not a quality that
to be desired of a programming language, even if it's only a keyword?

(Anyway, I think I'll stop here. This is too much opinion for any
further discussion to be useful.)

Regards,


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

Re: Request for feedback: deriving strategies syntax

[Bardur Arantsson]

On 2016-08-19 08:34, monkleyon--- via ghc-devs wrote:
>> Honestly, I don't care particularly much which exact word it becomes
>> just as long at isn't some 'cute' or obscurse[1] word.
>>
>> 'magic' belongs in the 'cute' category, I think and 'bespoke' belongs in
>> the latter.
> I'm native German. I never was in any English-speaking country in my
> life. Almost all my English media is from the USA. I'm not a tailor. Yet
> "bespoke" was familiar and instantly tells me what's important.
> So I may just be one point on the map, but I am not sure your argument
> that it is "obscure" is valid, sorry.
> 
> That being said, let me add a package of "a"s for all the times an
> English native complains that he has to learn a new word to program.
> Take a portion and pass it along, would you? ;)
> 
> Apropos learning words: while searching for information if "bespoke" is
> really obscure (I found none in either direction) I stumbled upon some
> (I think) not-yet-mentioned possible options
> 

I said it was *needlessly* obscure. There's absolutely no reason to
choose such a word in this case.

> * custom(i[zs]ed)?

This seems to convey the exact opposite when used in the programming
domain. When I 'customize' something or specify a 'custom' $something, I
expect that I, the programmer, am going to provide the
logic/behavior/whatever.

> * tailored

Just as 'bad' as bespoke -- and still has a sort of feeling of
'customized'. Bespoke at least has the very strong connotation of
"getting someone else to do it for you" whereas tailored doesn't *quite*
have that. (All, IMO, of course.)

Regards,

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

Re: Request for feedback: deriving strategies syntax

[Phil Ruffwind]

I would prefer "custom" simply because the word is used often enough in
computing that there is no chance of someone having to pull out a
dictionary for it.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Request for feedback: deriving strategies syntax

[Bardur Arantsson]

On 2016-08-19 03:45, Baldur Blöndal wrote:
> I haven't followed the thread but do we actually need a name for it,
> can't it be indicated by omission?
> ‘default’ or ‘builtin’ sounds okay

'default' is good too, IMO.



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

Re: Request for feedback: deriving strategies syntax

[Bardur Arantsson]

On 2016-08-18 20:46, Ryan Scott wrote:
> Bardur,
> 
> Since you don't like "bespoke", would you mind suggesting an
> alternative, or advocating for a previously mentioned idea? From [1],
> the ideas I've seen tossed around are:
> 
> * builtin
> * standard (Elliot Cameron suggested it here [2])
> * wiredin (Cater Schonwald suggested it here [3])
> * magic (Andres Löh suggested it here [4])
> * native
> * original
> * specialized (the above three are ad hoc suggestions I came up with
in a hurry)

(I think I did suggest 'builtin', but it was buried in a sentence, so it
was easy to miss.)

Honestly, I don't care particularly much which exact word it becomes
just as long at isn't some 'cute' or obscurse[1] word.

'magic' belongs in the 'cute' category, I think and 'bespoke' belongs in
the latter.

Of the remaining alternatives I like 'builtin' and 'standard' the best,
simply because they're common and not all that overloaded when it comes
to their meaning in programming languages.

Regards,

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

Re: Request for feedback: deriving strategies syntax

[Baldur Blöndal]

I haven't followed the thread but do we actually need a name for it, can't
it be indicated by omission?
‘default’ or ‘builtin’ sounds okay

2016-08-18 20:00 GMT+00:00 Nicolas Frisby :

> The Report specifies the semantics of most (all other than Generic?)
> derivation strategies that are baked-in to the compiler.
>
> https://www.haskell.org/onlinereport/haskell2010/
> haskellch11.html#x18-18200011
>
> I think this raises an issue of what *exactly* we are currently referring
> to as "bespoke". E.G. can it vary with the precise compiler being used?
> (Maybe your wiki page addresses this; I haven't clicked through.)
>
> But maybe "language-report" would supplant "bespoke". And perhaps
> "GHC-7.8" would also make sense, if the baked-in derivation scheme varies
> from the report's spec? Etc.
>
> HTH. -Nick
>
> On Thu, Aug 18, 2016, 12:24 Elliot Cameron  wrote:
>
>> Given the prevalence of spellings like "normalise" in common Haskell
>> packages, we might just be settling on British English. Being American
>> makes that a tad difficult on my end, but personally I can make peace with
>> it.
>>
>> On Thu, Aug 18, 2016 at 3:19 PM, Matthew Pickering <
>> matthewtpicker...@gmail.com> wrote:
>>
>>> I also like 'bespoke' but then it seems to be a much more common in
>>> British English than American English.
>>>
>>> On Thu, Aug 18, 2016 at 7:46 PM, Ryan Scott 
>>> wrote:
>>> > Bardur,
>>> >
>>> > Since you don't like "bespoke", would you mind suggesting an
>>> > alternative, or advocating for a previously mentioned idea? From [1],
>>> > the ideas I've seen tossed around are:
>>> >
>>> > * builtin
>>> > * standard (Elliot Cameron suggested it here [2])
>>> > * wiredin (Cater Schonwald suggested it here [3])
>>> > * magic (Andres Löh suggested it here [4])
>>> > * native
>>> > * original
>>> > * specialized (the above three are ad hoc suggestions I came up with
>>> in a hurry)
>>> >
>>> > Ryan S.
>>> > -
>>> > [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/
>>> DerivingStrategies#Alternativesyntax
>>> > [2] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012448.html
>>> > [3] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012450.html
>>> > [4] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012453.html
>>> > ___
>>> > 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
>>
>
> ___
> 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

Re: Request for feedback: deriving strategies syntax

[Nicolas Frisby]

The Report specifies the semantics of most (all other than Generic?)
derivation strategies that are baked-in to the compiler.

https://www.haskell.org/onlinereport/haskell2010/haskellch11.html#x18-18200011

I think this raises an issue of what *exactly* we are currently referring
to as "bespoke". E.G. can it vary with the precise compiler being used?
(Maybe your wiki page addresses this; I haven't clicked through.)

But maybe "language-report" would supplant "bespoke". And perhaps "GHC-7.8"
would also make sense, if the baked-in derivation scheme varies from the
report's spec? Etc.

HTH. -Nick

On Thu, Aug 18, 2016, 12:24 Elliot Cameron  wrote:

> Given the prevalence of spellings like "normalise" in common Haskell
> packages, we might just be settling on British English. Being American
> makes that a tad difficult on my end, but personally I can make peace with
> it.
>
> On Thu, Aug 18, 2016 at 3:19 PM, Matthew Pickering <
> matthewtpicker...@gmail.com> wrote:
>
>> I also like 'bespoke' but then it seems to be a much more common in
>> British English than American English.
>>
>> On Thu, Aug 18, 2016 at 7:46 PM, Ryan Scott 
>> wrote:
>> > Bardur,
>> >
>> > Since you don't like "bespoke", would you mind suggesting an
>> > alternative, or advocating for a previously mentioned idea? From [1],
>> > the ideas I've seen tossed around are:
>> >
>> > * builtin
>> > * standard (Elliot Cameron suggested it here [2])
>> > * wiredin (Cater Schonwald suggested it here [3])
>> > * magic (Andres Löh suggested it here [4])
>> > * native
>> > * original
>> > * specialized (the above three are ad hoc suggestions I came up with in
>> a hurry)
>> >
>> > Ryan S.
>> > -
>> > [1]
>> https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategies#Alternativesyntax
>> > [2] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012448.html
>> > [3] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012450.html
>> > [4] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012453.html
>> > ___
>> > 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
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Request for feedback: deriving strategies syntax

[Elliot Cameron]

Given the prevalence of spellings like "normalise" in common Haskell
packages, we might just be settling on British English. Being American
makes that a tad difficult on my end, but personally I can make peace with
it.

On Thu, Aug 18, 2016 at 3:19 PM, Matthew Pickering <
matthewtpicker...@gmail.com> wrote:

> I also like 'bespoke' but then it seems to be a much more common in
> British English than American English.
>
> On Thu, Aug 18, 2016 at 7:46 PM, Ryan Scott 
> wrote:
> > Bardur,
> >
> > Since you don't like "bespoke", would you mind suggesting an
> > alternative, or advocating for a previously mentioned idea? From [1],
> > the ideas I've seen tossed around are:
> >
> > * builtin
> > * standard (Elliot Cameron suggested it here [2])
> > * wiredin (Cater Schonwald suggested it here [3])
> > * magic (Andres Löh suggested it here [4])
> > * native
> > * original
> > * specialized (the above three are ad hoc suggestions I came up with in
> a hurry)
> >
> > Ryan S.
> > -
> > [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/
> DerivingStrategies#Alternativesyntax
> > [2] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012448.html
> > [3] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012450.html
> > [4] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012453.html
> > ___
> > 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

Re: Request for feedback: deriving strategies syntax

[Matthew Pickering]

I also like 'bespoke' but then it seems to be a much more common in
British English than American English.

On Thu, Aug 18, 2016 at 7:46 PM, Ryan Scott  wrote:
> Bardur,
>
> Since you don't like "bespoke", would you mind suggesting an
> alternative, or advocating for a previously mentioned idea? From [1],
> the ideas I've seen tossed around are:
>
> * builtin
> * standard (Elliot Cameron suggested it here [2])
> * wiredin (Cater Schonwald suggested it here [3])
> * magic (Andres Löh suggested it here [4])
> * native
> * original
> * specialized (the above three are ad hoc suggestions I came up with in a 
> hurry)
>
> Ryan S.
> -
> [1] 
> https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategies#Alternativesyntax
> [2] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012448.html
> [3] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012450.html
> [4] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012453.html
> ___
> 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

Re: Request for feedback: deriving strategies syntax

[Ryan Scott]

Bardur,

Since you don't like "bespoke", would you mind suggesting an
alternative, or advocating for a previously mentioned idea? From [1],
the ideas I've seen tossed around are:

* builtin
* standard (Elliot Cameron suggested it here [2])
* wiredin (Cater Schonwald suggested it here [3])
* magic (Andres Löh suggested it here [4])
* native
* original
* specialized (the above three are ad hoc suggestions I came up with in a hurry)

Ryan S.
-
[1] 
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategies#Alternativesyntax
[2] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012448.html
[3] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012450.html
[4] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012453.html
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Request for feedback: deriving strategies syntax

[Bardur Arantsson]

On 2016-08-18 07:44, Malcolm Wallace wrote:
> 
> On 18 Aug 2016, at 06:34, Bardur Arantsson wrote:
> 
>> Not a native (British) English speaker, but I've consumed a *lot* of UK
>> media over the last ~25-30 years and I can literally only recall having
>> heard "bespoke" used *once* and that was in the term "bespoke suit"
>> where you can sort-of guess its meaning from context. I believe this is
>> also the only context in which it's actually really used in British
>> English. (However, I'll let the native (British) English speakers chime
>> in on that.)
> 
> "Bespoke" is a reasonably common British English word, used in all of the 
> following phrases:
> 
> bespoke software
> bespoke solution
> bespoke furniture
> bespoke kitchen
> bespoke tailoring
> 
> The meaning is "specially and individually made for this client".  The 
> opposite of standard, off-the-shelf, pre-packaged.  It implies the outcome 
> was not automatable, even if the individual pieces being assembled were 
> machine-cut.
> 

Thanks,

Mildly interestingly, both the online M-W and the online OED list only
the clothing by example. (Though the definitions don't *preclude* any
other type of goods.)

> "In the U.S., bespoke software is often called custom or custom-designed 
> software." http://whatis.techtarget.com/definition/bespoke
> 

AFAIUI "custom", alas, doesn't really work in this context. :(

Anyway, regardless of all that: "bespoke" is still a needlessly obscure
word, IMO. Ergonomics matter in programming languages.

Regards,

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

RE: Request for feedback: deriving strategies syntax

[Simon Peyton Jones via ghc-devs]

Personally I like 'bespoke'.

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
|  Richard Eisenberg
|  Sent: 18 August 2016 04:14
|  To: Ryan Scott <ryan.gl.sc...@gmail.com>
|  Cc: Andres Loeh <m...@andres-loeh.de>; GHC developers 
|  Subject: Re: Request for feedback: deriving strategies syntax
|  
|  
|  > On Aug 12, 2016, at 2:31 PM, Ryan Scott <ryan.gl.sc...@gmail.com>
|  wrote:
|  >
|  > I can understand your reaction to the word "bespoke". I certainly
|  > never use it in daily conversation, and it's only from Richard's
|  > assurance (and from consulting a dictionary) that I feel confident
|  > about using it in this context.
|  
|  Oh dear. Please don't take my word for it. I (an American) do not use
|  the word in my native lexicon but instead adopted it after living in
|  England for several years. Would someone who uses this word natively
|  (e.g., someone who has lived in England for more than several years)
|  vouch for this usage?
|  
|  Richard
|  ___
|  ghc-devs mailing list
|  ghc-devs@haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
|  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs=01%7c01%7csimonpj%40microsoft.com%7c89ab823b9cd044d63bc008d3
|  c715acff%7c72f988bf86f141af91ab2d7cd011db47%7c1=gfyq6BECLG97z432
|  0AJH03zGBGi3ETvdA0%2f8uTcm6vA%3d
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Request for feedback: deriving strategies syntax

[Malcolm Wallace]

On 18 Aug 2016, at 06:34, Bardur Arantsson wrote:

> Not a native (British) English speaker, but I've consumed a *lot* of UK
> media over the last ~25-30 years and I can literally only recall having
> heard "bespoke" used *once* and that was in the term "bespoke suit"
> where you can sort-of guess its meaning from context. I believe this is
> also the only context in which it's actually really used in British
> English. (However, I'll let the native (British) English speakers chime
> in on that.)

"Bespoke" is a reasonably common British English word, used in all of the 
following phrases:

bespoke software
bespoke solution
bespoke furniture
bespoke kitchen
bespoke tailoring

The meaning is "specially and individually made for this client".  The opposite 
of standard, off-the-shelf, pre-packaged.  It implies the outcome was not 
automatable, even if the individual pieces being assembled were machine-cut.

"In the U.S., bespoke software is often called custom or custom-designed 
software." http://whatis.techtarget.com/definition/bespoke


Regards,
Malcolm

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

Re: Request for feedback: deriving strategies syntax

[Bardur Arantsson]

On 2016-08-12 20:31, Ryan Scott wrote:
> On the subject of alternative names, you may be interested in reading
> this section of the DerivingSyntax wiki page [2], which lists other
> names besides "bespoke" and "builtin" that have been tossed around as
> ideas. They include:
> 
> * magic
> * wiredin
> * standard
> * native
> * original
> * specialized
> 

Can we please just go with the obvious "builtin"? There's no need for
willful obscurity here.

Not a native (British) English speaker, but I've consumed a *lot* of UK
media over the last ~25-30 years and I can literally only recall having
heard "bespoke" used *once* and that was in the term "bespoke suit"
where you can sort-of guess its meaning from context. I believe this is
also the only context in which it's actually really used in British
English. (However, I'll let the native (British) English speakers chime
in on that.)

Regards,

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

Re: Request for feedback: deriving strategies syntax

[Richard Eisenberg]

> On Aug 12, 2016, at 2:31 PM, Ryan Scott  wrote:
> 
> I can understand your reaction to the word "bespoke". I certainly
> never use it in daily conversation, and it's only from Richard's
> assurance (and from consulting a dictionary) that I feel confident
> about using it in this context.

Oh dear. Please don't take my word for it. I (an American) do not use the word 
in my native lexicon but instead adopted it after living in England for several 
years. Would someone who uses this word natively (e.g., someone who has lived 
in England for more than several years) vouch for this usage?

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

Re: Request for feedback: deriving strategies syntax

[Matthew Farkas-Dyck via ghc-devs]

On 12/08/2016, Ryan Scott  wrote:
> I hope you don't interpret this e-mail as dismissing your concerns.
> It's just that I have to pick _some_ name for this keyword, and after
> considering all of the options thus far, "bespoke" is the one that
> seems the most palatable.

Fair enough, like i said, it's not significantly worse than any other
nomenclature a newcomer must learn, and i haven't had a better idea ☺
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Request for feedback: deriving strategies syntax

[Ryan Scott]

Hi Simon,

> * Current specification is here: ...

It's in a Haskell wiki page: [1]. This summarizes the current proposed
syntax for -XDerivingStrategies, how GHC will choose a strategy in the
absence of an explicit strategy, and also goes over some alternative
syntaxes that have been proposed previously for the sake of archiving.

> * Patch is here: ...  (complete?)

It's on Phabricator: [2].

> * Unresolved issues?  Ready to review?

It's ready for review. It's incorporated all of the changes discussed
on this e-mail thread, including renaming the "builtin" strategy to
"bespoke", and including a link to the DerivingStrategies wiki in a
Note.

You left some inline comments on an earlier draft—I responded to some
of them with questions [3], since I wasn't clear what you were asking.

Ryan S.
-
[1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategies
[2] https://phabricator.haskell.org/D2280
[3] https://phabricator.haskell.org/D2280#inline-20129

On Thu, Aug 11, 2016 at 6:36 AM, Simon Peyton Jones
<simo...@microsoft.com> wrote:
> Ryan
>
> I've been on holiday, and there's been a lot of traffic on this 
> deriving-strategy thread.
>
> Would you like to send an email summarising the state of play. Eg
> * Current specification is here: ...
> * Patch is here: ...  (complete?)
> * Unresolved issues?  Ready to review?
>
> Thanks
>
> Simon
>
> | -Original Message-
> | From: Ryan Scott [mailto:ryan.gl.sc...@gmail.com]
> | Sent: 02 August 2016 23:59
> | To: Simon Peyton Jones <simo...@microsoft.com>
> | Cc: Richard Eisenberg <e...@cis.upenn.edu>; Andres Loeh <mail@andres-
> | loeh.de>; GHC developers <ghc-devs@haskell.org>
> | Subject: Re: Request for feedback: deriving strategies syntax
> |
> | 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/DerivingStrate
> | gies
> |
> | On Mon, Jul 18, 2016 at 5:54 PM, Simon Peyton Jones
> | <simo...@microsoft.com> 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:ghc-devs-boun...@haskell.org] On Behalf Of Ryan
> | Scott
> | > Sent: 18 July 2016 15:00
> | > To: Richard Eisenberg <e...@cis.upenn.edu>
> | > Cc: Andres Loeh <m...@andres-loeh.de>; GHC developers  | d...@haskell.org>
> | > 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 &q

RE: Request for feedback: deriving strategies syntax

[Simon Peyton Jones via ghc-devs]

Ryan

I've been on holiday, and there's been a lot of traffic on this 
deriving-strategy thread.

Would you like to send an email summarising the state of play. Eg
* Current specification is here: ...
* Patch is here: ...  (complete?)
* Unresolved issues?  Ready to review?

Thanks

Simon

| -Original Message-
| From: Ryan Scott [mailto:ryan.gl.sc...@gmail.com]
| Sent: 02 August 2016 23:59
| To: Simon Peyton Jones <simo...@microsoft.com>
| Cc: Richard Eisenberg <e...@cis.upenn.edu>; Andres Loeh <mail@andres-
| loeh.de>; GHC developers <ghc-devs@haskell.org>
| Subject: Re: Request for feedback: deriving strategies syntax
| 
| 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/DerivingStrate
| gies
| 
| On Mon, Jul 18, 2016 at 5:54 PM, Simon Peyton Jones
| <simo...@microsoft.com> 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:ghc-devs-boun...@haskell.org] On Behalf Of Ryan
| Scott
| > Sent: 18 July 2016 15:00
| > To: Richard Eisenberg <e...@cis.upenn.edu>
| > Cc: Andres Loeh <m...@andres-loeh.de>; GHC developers 
| > 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 

Re: Request for feedback: deriving strategies syntax

[Shayan Najd]

Hi all,

Shayan, have you written anything describing how things are going?


Ben,
  thank you for reaching out.

I am not sure about the history and the context of the discussions in this
thread so far, but here is a brief description of what we intend to do and
how far we have come so far.

The idea is simple: allow grand larceny, with a clear conscience!
We are trying to allow metaprograms to directly access and reuse the
"native" machinery inside the compiler. There is no need to have a separate
representation of syntax, and the associated sets of tools, as in Template
Haskell, or even as in third-party libraries like Haskell-Src-Exts (HSE)
and others in Haskell-Suite. GHC has a "native" representation of terms,
with many tools already built on top of that, including the compiler passes
like the renamer, or the typechecker. We would certainly like to unify
these representations and tools as much as possible, and allow metaprograms
to directly access these internal machineries.

The eventual goal is indeed more than sole reuse of the AST in GHC (HsSyn);
metaprograms should also be able to reuse the "infrastructure" like the
different environments and monads used for name resolution or typechecking.
If we are to treat `deriving`, and many other similar constructs in the
language simply as metaprograms, access to types is *sometimes* crucial:
they describe a type-directed elaboration process.
I am a strong advocate of such simplifications for both the front-end
(i.e., how users perceive constructs in the language), and the back-end
(i.e., how the compiler implements them). However, there is a huge, often
underestimated, gap between having these constructs as built-in, and
 having them as yet another metaprogram. The gap is both in theory, e.g.,
the equational and algebraic properties of the constructs, and in practice,
e.g., handling the error messages and maintain the general
macro/metaprogramming system allowing for such definitions. Many
researchers, including me, have worked on these problems; there is still
work to be done. We can discuss some of these related works, if you are
interested.

For now, as the first step, we are focusing on how to reuse GHC AST (HsSyn)
for metaprogramming. The immediate problem with reusing GHC AST is that it
comes with a large set of extra fields and constructors carrying the
information only necessary for the passes inside GHC.
Users (metaprogrammers?) do not want to, and do not need to, deal with
these extra fields and constructors. Moreover, the AST should be,
to some degree, easy to use, and we have no exact metric for the ease of
use.

Our solution is twofold, addressing the two mentioned problems:
  (a) after a rather deep analysis, we have come up with a simple, yet
powerful, encoding of extensible ASTs that allows us to extend a base AST
with new fields and constructors;
  (b) we are updating GHC AST to match HSE AST, hence unifying the two
(based on its popularity, we can say HSE is easy enough to use).

In theory, due to (a), code for GHC passes do not need to change.
In practice, due to (b), we may need to update the code in GHC passes in
some cases.

It is needless to say, that this is all work in progress.
Following Simon's suggestion, I am planning to give a talk on this in
Haskell Implementors' Workshop in Japan. But since then, for further
information, you may be brave enough to read our sketchy notes / pieces of
code:
- An example using the extensible encoding (a bit outdated variant though):

https://github.com/shayan-najd/NativeMetaprogramming/blob/master/HsSyn/Example.hs
- Discussion on why this extensible encoding is suitable:

https://github.com/shayan-najd/NativeMetaprogramming/wiki/Extensions-&-Annotations
- To see progress on unifying HSE AST and GHC AST compare
  the updated GHC AST at

https://github.com/shayan-najd/NativeMetaprogramming/blob/master/HsSyn/SyntaxExtensibleAutoSplitted.hs
  and the updated HSE AST at

https://github.com/shayan-najd/NativeMetaprogramming/blob/master/HSE/SyntaxExtensibleAuto.hs
   They should be line-by-line comparable unless the comments says so
otherwise.

There is much to be done without a doubt, specially to synchronise with and
learn form communities working on similar topics

Yours,
  Shayan

On Fri, Aug 5, 2016 at 11:06 AM, Ben Gamari  wrote:

> Ryan Scott  writes:
>
> > Sorry for not including the full context on that link. It's part of a
> > Summer of Haskell 2016 project called Native Metaprogramming in
> > Haskell [1] (a.k.a. Introspective Template Haskell [2]), aiming to fix
> > Trac #11081 [3].
> >
> On this note, it would be great to hear a bit about the state of this
> project. Shayan, have you written anything describing how things are
> going? It would be great if you could update the Wiki page [2]
> describing a bit about the approach you have taken and the current state
> of your implementation.
>
> Cheers,
>
> - Ben
>

Re: Request for feedback: deriving strategies syntax

[Bardur Arantsson]

On 2016-08-05 11:06, Ben Gamari wrote:
> Ryan Scott  writes:
> 
>> Sorry for not including the full context on that link. It's part of a
>> Summer of Haskell 2016 project called Native Metaprogramming in
>> Haskell [1] (a.k.a. Introspective Template Haskell [2]), aiming to fix
>> Trac #11081 [3].
>>
> On this note, it would be great to hear a bit about the state of this
> project. Shayan, have you written anything describing how things are
> going? It would be great if you could update the Wiki page [2]
> describing a bit about the approach you have taken and the current state
> of your implementation.
> 

Just a little aside: AFAICT the idea here was originally to reuse the
compiler's internal AST representation. I'd be really interested to hear
if that's changed.

This compes along with a little cautionary note: The Scala people
originally did this for their macro support and it's being abandoned in
favor of something called TASTY which is a different (simplified?)
representation of the Scala AST. (There were a lot of other problems
with the Scala macro implementation which is caused by simply being
intimately tied to compiler internals in *other* ways.) Obviously, all
of this is AFAIUI and my understanding may not exactly be great, but
regardless I think it's worth looking into Scala/TASTY and why the Scala
people have (apparently) chosen it as the solution over the existing one.

Regards,

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

Re: Request for feedback: deriving strategies syntax

[Ben Gamari]

Ryan Scott  writes:

> Sorry for not including the full context on that link. It's part of a
> Summer of Haskell 2016 project called Native Metaprogramming in
> Haskell [1] (a.k.a. Introspective Template Haskell [2]), aiming to fix
> Trac #11081 [3].
>
On this note, it would be great to hear a bit about the state of this
project. Shayan, have you written anything describing how things are
going? It would be great if you could update the Wiki page [2]
describing a bit about the approach you have taken and the current state
of your implementation.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Request for feedback: deriving strategies syntax

[Ryan Scott]

Sorry for not including the full context on that link. It's part of a
Summer of Haskell 2016 project called Native Metaprogramming in
Haskell [1] (a.k.a. Introspective Template Haskell [2]), aiming to fix
Trac #11081 [3].

Ryan S.
-
[1] https://github.com/shayan-najd/NativeMetaprogramming
[2] https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Introspective
[3] https://ghc.haskell.org/trac/ghc/ticket/11081
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Request for feedback: deriving strategies syntax

[Ryan Scott]

> I do not understand "not portable" here. Do you mean that some architectures 
> don't support TH?

Template Haskell doesn't play nicely with cross compilation [1] or
stage-1 compilers, so Template Haskell is simply a non-starter for a
lot of uses. It's why the GHC codebase and boot libraries largely
don't use the -XTemplateHaskell extension (aside from the test suite,
of course).

> What staging issues?
>
> I'm imagining here having `deriving Blah` be surface syntax that desugars 
> into some TH splice. You keep the nice user-facing syntax, but make the 
> deriving mechanism itself specified in TH code.

That won't currently work with the way TH stages its splices. For
example, the following code:

{-# LANGUAGE PackageImports, TemplateHaskell #-}

import "deriving-compat" Data.Eq.Deriving

bar :: Bar
bar = Bar

data Foo = Foo
$(deriveEq ''Foo)

data Bar = Bar
$(deriveEq ''Bar)

will fail to compile because of the staging restrictions on Template
Haskell splices, whereas replacing the splices with `deriving Eq`
would make it compile.

> It's an interesting idea, but one probably best tackled after the current 
> proposal.

Completely agreed. :)

Ryan S.
-
[1] https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/CrossCompilation
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Request for feedback: deriving strategies syntax

[Bardur Arantsson]

On 2016-08-04 02:50, Ryan Scott wrote:
>  I'm
> holding out hope that the work in
> https://github.com/shayan-najd/NativeMetaprogramming makes things
> nicer soon, and then we can revisit this idea.

Are there any papers on this? (Or even just blog posts and such.) Sounds
really intriguing, but obvious searches didn't find anything.

Regards,

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

Re: Request for feedback: deriving strategies syntax

[Brandon Allbery]

On Wed, Aug 3, 2016 at 10:52 PM, Richard Eisenberg 
wrote:

> I do not understand "not portable" here. Do you mean that some
> architectures don't support TH?


Sounded to me like they're targeting the standards path, which means not
tying it to something that's fairly inherently GHC specific.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Request for feedback: deriving strategies syntax

[Richard Eisenberg]

> On Aug 3, 2016, at 8:50 PM, Ryan Scott  wrote:
> 
> * Template Haskell: Not portable. Staging issues make it hard to use
> as a drop-in replacement for the `deriving` keyword

I do not understand "not portable" here. Do you mean that some architectures 
don't support TH?

What staging issues?

I'm imagining here having `deriving Blah` be surface syntax that desugars into 
some TH splice. You keep the nice user-facing syntax, but make the deriving 
mechanism itself specified in TH code.

It's an interesting idea, but one probably best tackled after the current 
proposal.

Richard

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

Re: Request for feedback: deriving strategies syntax

[Ryan Scott]

> How much of this derivation machinery could NOT be implemented by means of
> some kind of a (hypothetical) type-backed metaprogramming facility?

I think this would be a wonderful thing to have. Matthew Pickering
(cc'd) has expressed a desire to have all the logic for the `bespoke`
deriving strategies compartmentalized into a library that could easily
be expanded on in the future to support more typeclasses in base.
(Bifunctor, anyone?)

Unfortunately, each of the major players in today's Haskell
metaprogramming scene that I'm aware of have some downfalls that make
them unsuitable as `deriving` replacements:

* Template Haskell: Not portable. Staging issues make it hard to use
as a drop-in replacement for the `deriving` keyword
* GHC generics: Can't express all the optimizations that the bespoke
`deriving` algorithms perform. Unperformant.
* Haskell preprocessors: Difficult to integrate in a typical GHC
workflow. Probably wouldn't have all the metadata you'd need to be
feature-complete with what `deriving` does today.

The way I see it, the whole `deriving` business as it currently stands
today is a somewhat-grotesque-but-darn-useful hack that gets around
the lack of a truly nice metaprogramming facility in Haskell. I'm
holding out hope that the work in
https://github.com/shayan-najd/NativeMetaprogramming makes things
nicer soon, and then we can revisit this idea. Until then,
-XDerivingStrategies provides a way to contain some of the madness of
`deriving` after having many features tacked onto it in recent GHC
releases.

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

Re: Request for feedback: deriving strategies syntax

[Edward Kmett]

It has the benefit that nothing lowercase would ever derive in that
position so it is a strict extension of the current syntax. So even it
builtin or whatever is a conditional keyword like qualified and as, I don't
see any issues with it.

'bespoke' does make me smile, though. =)

-Edward

On Sun, Jul 17, 2016 at 10:24 PM, Richard Eisenberg 
wrote:

> Of the three options from Ryan's first email in this thread, only the
> third is palatable to me (with the separate `deriving` clauses).
>
> I would like to mention that I don't see any real obstacles to something
> like
>
> > newtype ...
> >  deriving (Eq, default ToJSON, builtin Ord, newtype Monoid)
>
> That is, one `deriving` clause where each element is optionally prefixed
> with a keyword. On the ticket (#10598), it is suggested that parsing these
> would be hard. I agree that parsing these would be annoying, but I do not
> think that they are actually ambiguous. Avoiding a few hours of pain in the
> parser should not be our motivation for choosing a syntax we will all live
> with for years. For `default` and `newtype`, parsing is actually easy. If
> we want to keep the `builtin` pseudo-keyword, we could always parse as a
> type and then have some non-parser code examine the resulting AST and sort
> it out. (This is done in several other dark corners of the parser already.)
>
> Separately, I'm not enamored of the `builtin` keyword. The one idea I can
> suggest in this space (somewhat tongue-in-cheek, but feel free to take it
> seriously) is `bespoke` -- after all, each "builtin" instance must be
> generated by code written specifically for that class, which fits the
> English definition of bespoke nicely. "Which deriving mechanism do want?"
> "The bespoke one, please." And then GHC can boast that it has the classiest
> keyword of any programming language. :)
>
> Richard
>
> On Jul 16, 2016, at 10:02 PM, Ryan Scott  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] 

Re: Request for feedback: deriving strategies syntax

[Kosyrev Serge]

Kosyrev Serge <_deepf...@feelingofgreen.ru> writes:
> How much of this derivation machinery could NOT be implemented by means of
> some kind of a (hypothetical) type-backed metaprogramming facility?
>
> The beauty of an open implementation[1] allowed by such a thing is that:

I apologize for the unfortunate metacircular logic in the below passage:

>   1. uniformity of definition of the desugaring transformation
>  would have followed, and from that:
>
>  - the "bespoke" derivation mechanism will suddenly become
>explainable in a language shared by all derivation mechanisms:
>
>- the separate derivation strategies as separate, named macro
>  transformations, using a common library of type-level and other
>  tools -- mostly those already in existence
>- the combined strategy as an overarching macro tranformation

It should instead read as:

   1. uniformity of expression of the desugaring transformation
  would have followed, in the following way:

  - the overall derivation mechanism is to become expressible
through the following composition:

- the separate derivation strategies are to become separate,
  named macro transformations, using a common library of
  type-level and other tools -- mostly those already in
  existence

  - this aforementioned common library is explicitly required to
be sufficiently powerful to able to express the "bespoke"
derivation mechanism

- the combined strategy as an overarching macro tranformation

The rest stands as is:

>  2. because of above, we get a starting point from which we can
> evolve something that can be meaningfully standartized, without a
> feeling of shame or guilt -- we now have a language describing the
> problem domain, that can be un-tied from a particular implementation
>
>  3. in-editor macroexpansion is a proven, working concept in the realm
> of Proper Metaprogramming (viz. Common Lisp etc.), and it would
> basically eliminate guesswork from user workflows
>
>  ..or is this all a violent pipe dream?

-- 
с уважениeм / respectfully,
Косырев Сергей
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Request for feedback: deriving strategies syntax

[Kosyrev Serge]

Ryan Scott  writes:
> 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:



How much of this derivation machinery could NOT be implemented by means of
some kind of a (hypothetical) type-backed metaprogramming facility?

The beauty of an open implementation[1] allowed by such a thing is that:

  1. uniformity of definition of the desugaring transformation
 would have followed, and from that:

 - the "bespoke" derivation mechanism will suddenly become
   explainable in a language shared by all derivation mechanisms:

   - the separate derivation strategies as separate, named macro
 transformations, using a common library of type-level and other
 tools -- mostly those already in existence
   - the combined strategy as an overarching macro tranformation

 - therefore, users would have been empowered to easily provide
   derivation mechanisms of the same power as "bespoke", plugging
   into the aforementioned scheme

  2. because of above, we get a starting point from which we can
 evolve something that can be meaningfully standartized, without a
 feeling of shame or guilt -- we now have a language describing the
 problem domain, that can be un-tied from a particular implementation

  3. in-editor macroexpansion is a proven, working concept in the realm
 of Proper Metaprogramming (viz. Common Lisp etc.), and it would
 basically eliminate guesswork from user workflows

..or is this all a violent pipe dream?

-- 
с уважениeм / respectfully,
Косырев Сергей
--
1. The concept of an "open implementation" comes from a paper by
   Kiczales and Paepcke.  Although the concept comes from the context of
   metaobject protocols the core idea seems universally applicable --
   careful exposure and reification of implementation machinery can be
   beneficial.
   
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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  wrote:
>
>> On Aug 2, 2016, at 6:59 PM, Ryan Scott  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
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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
<simo...@microsoft.com> 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:ghc-devs-boun...@haskell.org] On Behalf Of Ryan Scott
> Sent: 18 July 2016 15:00
> To: Richard Eisenberg <e...@cis.upenn.edu>
> Cc: Andres Loeh <m...@andres-loeh.de>; GHC developers <ghc-devs@haskell.org>
> 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
> ghc-devs@haskell.org
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cea562a7e9e494f07cede08d3af13cbc7%7c72f988bf86f141af91ab2d7cd011db47%7c1=rKTWOkEZsKUdDOTnk7WL2BNx1lf36uelef4JDg0pX44%3d
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Request for feedback: deriving strategies syntax

[Simon Peyton Jones via ghc-devs]

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:ghc-devs-boun...@haskell.org] On Behalf Of Ryan Scott
Sent: 18 July 2016 15:00
To: Richard Eisenberg <e...@cis.upenn.edu>
Cc: Andres Loeh <m...@andres-loeh.de>; GHC developers <ghc-devs@haskell.org>
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
ghc-devs@haskell.org
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cea562a7e9e494f07cede08d3af13cbc7%7c72f988bf86f141af91ab2d7cd011db47%7c1=rKTWOkEZsKUdDOTnk7WL2BNx1lf36uelef4JDg0pX44%3d
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

Re: Request for feedback: deriving strategies syntax

[Andres Loeh]

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

Re: Request for feedback: deriving strategies syntax

[Richard Eisenberg]

> On Jul 18, 2016, at 9:59 AM, Ryan Scott  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
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

Re: Request for feedback: deriving strategies syntax

[Richard Eisenberg]

> On Jul 18, 2016, at 2:54 AM, Andres Loeh  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
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Request for feedback: deriving strategies syntax

[Andres Loeh]

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  wrote:
> I'm pursuing a fix to Trac #10598 [1], an issue in which GHC users do
> not have fine-grained control over which strategy to use when deriving
> an instance, especially when multiple extensions like
> -XGeneralizedNewtypeDeriving and -XDeriveAnyClass are enabled
> simultaneously. I have a working patch up at [2] which would fix the
> issue, but there's still a lingering question of what the right syntax
> is to use here. I want to make sure I get this right, so I'm
> requesting input from the community.
>
> To condense the conversation in [1], there are three means by which
> you can derive an instance in GHC today:
>
> 1. -XGeneralizedNewtypeDeriving
> 2. -XDeriveAnyClass
> 3. GHC's builtin algorithms (which are used for deriving Eq, Show,
> Functor, Generic, Data, etc.)
>
> The problem is that it's sometimes hard to know which of the three
> will kick in when you say `deriving C`. To resolve this ambiguity, I
> want to introduce the -XDerivingStrategies extension, where a user can
> explicitly request which of the above ways to derive an instance.
>
> Here are some of the previously proposed syntaxes for this feature,
> with their perceived pros and cons:
>
> - Pragmas
>   * Examples:
>   - newtype T a = T a deriving ({-# BUILTIN #-} Eq, {-# GND #-}
> Ord, {-# DAC #-} Read, Show)
>   - deriving {-# BUILTIN #-} instance Functor T
>   * Pros:
>   - Backwards compatible
>   - Requires no changes to Template Haskell
>   * Cons:
>   - Unlike other pragmas, these ones can affect the semantics of a program
> - Type synonyms
>   * Examples:
>   - newtype T a = T a deriving (Builtin Eq, GND Ord, DAC Read, Show)
>   - deriving instance Builtin (Functor T)
>   * Pros:
>   - Requires no Template Haskell or parser changes, just some
> magic in the typechecker
>   - Backwards compatible (back to GHC 7.6)
>   * Cons:
>   - Some developers objected to the idea of imbuing type synonyms
> with magical properties
> - Multiple deriving clauses, plus new keywords
>   * Examples:
>   - newtype T a = T a
>   deriving Show
>   deriving builtin instance (Eq, Foldable)
>   deriving newtype instance Ord
>   deriving anyclass instance Read
>   - deriving builtin instance Functor T
>   * Pros:
>   - Doesn't suffer from the same semantic issues as the other suggestions
>   - (Arguably) the most straightforward-looking syntax
>   * Cons:
>   - Requires breaking changes to Template Haskell
>   - Changes the parser and syntax significantly
>
> Several GHC devs objected to the first two of the above suggestions in
> [1], so I chose to implement the "Multiple deriving clauses, plus new
> keywords" option in [2]. However, I'd appreciate further discussion on
> the above options, which one you prefer, and if you have other
> suggestions for syntax to use.
>
> Ryan S.
> -
> [1] https://ghc.haskell.org/trac/ghc/ticket/10598
> [2] https://phabricator.haskell.org/D2280
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Request for feedback: deriving strategies syntax

[Richard Eisenberg]

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  wrote:

> I'm pursuing a fix to Trac #10598 [1], an issue in which GHC users do
> not have fine-grained control over which strategy to use when deriving
> an instance, especially when multiple extensions like
> -XGeneralizedNewtypeDeriving and -XDeriveAnyClass are enabled
> simultaneously. I have a working patch up at [2] which would fix the
> issue, but there's still a lingering question of what the right syntax
> is to use here. I want to make sure I get this right, so I'm
> requesting input from the community.
> 
> To condense the conversation in [1], there are three means by which
> you can derive an instance in GHC today:
> 
> 1. -XGeneralizedNewtypeDeriving
> 2. -XDeriveAnyClass
> 3. GHC's builtin algorithms (which are used for deriving Eq, Show,
> Functor, Generic, Data, etc.)
> 
> The problem is that it's sometimes hard to know which of the three
> will kick in when you say `deriving C`. To resolve this ambiguity, I
> want to introduce the -XDerivingStrategies extension, where a user can
> explicitly request which of the above ways to derive an instance.
> 
> Here are some of the previously proposed syntaxes for this feature,
> with their perceived pros and cons:
> 
> - Pragmas
>  * Examples:
>  - newtype T a = T a deriving ({-# BUILTIN #-} Eq, {-# GND #-}
> Ord, {-# DAC #-} Read, Show)
>  - deriving {-# BUILTIN #-} instance Functor T
>  * Pros:
>  - Backwards compatible
>  - Requires no changes to Template Haskell
>  * Cons:
>  - Unlike other pragmas, these ones can affect the semantics of a program
> - Type synonyms
>  * Examples:
>  - newtype T a = T a deriving (Builtin Eq, GND Ord, DAC Read, Show)
>  - deriving instance Builtin (Functor T)
>  * Pros:
>  - Requires no Template Haskell or parser changes, just some
> magic in the typechecker
>  - Backwards compatible (back to GHC 7.6)
>  * Cons:
>  - Some developers objected to the idea of imbuing type synonyms
> with magical properties
> - Multiple deriving clauses, plus new keywords
>  * Examples:
>  - newtype T a = T a
>  deriving Show
>  deriving builtin instance (Eq, Foldable)
>  deriving newtype instance Ord
>  deriving anyclass instance Read
>  - deriving builtin instance Functor T
>  * Pros:
>  - Doesn't suffer from the same semantic issues as the other suggestions
>  - (Arguably) the most straightforward-looking syntax
>  * Cons:
>  - Requires breaking changes to Template Haskell
>  - Changes the parser and syntax significantly
> 
> Several GHC devs objected to the first two of the above suggestions in
> [1], so I chose to implement the "Multiple deriving clauses, plus new
> keywords" option in [2]. However, I'd appreciate further discussion on
> the above options, which one you prefer, and if you have other
> suggestions for syntax to use.
> 
> Ryan S.
> -
> [1] https://ghc.haskell.org/trac/ghc/ticket/10598
> [2] https://phabricator.haskell.org/D2280
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 

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

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

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  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  > 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"  > 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  > wrote:
> >> > Oleg Grenrus > writes:
> >> >
> >> >> Should we test drive 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
> >> 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

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  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"  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  wrote:
>> > Oleg Grenrus  writes:
>> >
>> >> Should we test drive 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
>> 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

Re: Request for feedback: deriving strategies syntax

[Elliot Cameron]

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"  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  wrote:
> > Oleg Grenrus  writes:
> >
> >> Should we test drive 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
> 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

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  wrote:
> Oleg Grenrus  writes:
>
>> Should we test drive 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
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Request for feedback: deriving strategies syntax

[Ben Gamari]

Oleg Grenrus  writes:

> Should we test drive 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



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Request for feedback: deriving strategies syntax

[Alexey Vagarenko]

>
> - 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
`NewtypeD Cxt

 Name

 [TyVarBndr
]
(Maybe

 Kind

) Con

 Cxt

`
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 :

> I'm pursuing a fix to Trac #10598 [1], an issue in which GHC users do
> not have fine-grained control over which strategy to use when deriving
> an instance, especially when multiple extensions like
> -XGeneralizedNewtypeDeriving and -XDeriveAnyClass are enabled
> simultaneously. I have a working patch up at [2] which would fix the
> issue, but there's still a lingering question of what the right syntax
> is to use here. I want to make sure I get this right, so I'm
> requesting input from the community.
>
> To condense the conversation in [1], there are three means by which
> you can derive an instance in GHC today:
>
> 1. -XGeneralizedNewtypeDeriving
> 2. -XDeriveAnyClass
> 3. GHC's builtin algorithms (which are used for deriving Eq, Show,
> Functor, Generic, Data, etc.)
>
> The problem is that it's sometimes hard to know which of the three
> will kick in when you say `deriving C`. To resolve this ambiguity, I
> want to introduce the -XDerivingStrategies extension, where a user can
> explicitly request which of the above ways to derive an instance.
>
> Here are some of the previously proposed syntaxes for this feature,
> with their perceived pros and cons:
>
> - Pragmas
>   * Examples:
>   - newtype T a = T a deriving ({-# BUILTIN #-} Eq, {-# GND #-}
> Ord, {-# DAC #-} Read, Show)
>   - deriving {-# BUILTIN #-} instance Functor T
>   * Pros:
>   - Backwards compatible
>   - Requires no changes to Template Haskell
>   * Cons:
>   - Unlike other pragmas, these ones can affect the semantics of a
> program
> - Type synonyms
>   * Examples:
>   - newtype T a = T a deriving (Builtin Eq, GND Ord, DAC Read, Show)
>   - deriving instance Builtin (Functor T)
>   * Pros:
>   - Requires no Template Haskell or parser changes, just some
> magic in the typechecker
>   - Backwards compatible (back to GHC 7.6)
>   * Cons:
>   - Some developers objected to the idea of imbuing type synonyms
> with magical properties
> - Multiple deriving clauses, plus new keywords
>   * Examples:
>   - newtype T a = T a
>   deriving Show
>   deriving builtin instance (Eq, Foldable)
>   deriving newtype instance Ord
>   deriving anyclass instance Read
>   - deriving builtin instance Functor T
>   * Pros:
>   - Doesn't suffer from the same semantic issues as the other
> suggestions
>   - (Arguably) the most straightforward-looking syntax
>   * Cons:
>   - Requires breaking changes to Template Haskell
>   - Changes the parser and syntax significantly
>
> Several GHC devs objected to the first two of the above suggestions in
> [1], so I chose to implement the "Multiple deriving clauses, plus new
> keywords" option in [2]. However, I'd appreciate further discussion on
> the above options, which one you prefer, and if you have other
> suggestions for syntax to use.
>
> Ryan S.
> -
> [1] https://ghc.haskell.org/trac/ghc/ticket/10598
> [2] https://phabricator.haskell.org/D2280
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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  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  wrote:
>> 
>> I'm pursuing a fix to Trac #10598 [1], an issue in which GHC users do
>> not have fine-grained control over which strategy to use when deriving
>> an instance, especially when multiple extensions like
>> -XGeneralizedNewtypeDeriving and -XDeriveAnyClass are enabled
>> simultaneously. I have a working patch up at [2] which would fix the
>> issue, but there's still a lingering question of what the right syntax
>> is to use here. I want to make sure I get this right, so I'm
>> requesting input from the community.
>> 
>> To condense the conversation in [1], there are three means by which
>> you can derive an instance in GHC today:
>> 
>> 1. -XGeneralizedNewtypeDeriving
>> 2. -XDeriveAnyClass
>> 3. GHC's builtin algorithms (which are used for deriving Eq, Show,
>> Functor, Generic, Data, etc.)
>> 
>> The problem is that it's sometimes hard to know which of the three
>> will kick in when you say `deriving C`. To resolve this ambiguity, I
>> want to introduce the -XDerivingStrategies extension, where a user can
>> explicitly request which of the above ways to derive an instance.
>> 
>> Here are some of the previously proposed syntaxes for this feature,
>> with their perceived pros and cons:
>> 
>> - Pragmas
>>  * Examples:
>>  - newtype T a = T a deriving ({-# BUILTIN #-} Eq, {-# GND #-}
>> Ord, {-# DAC #-} Read, Show)
>>  - deriving {-# BUILTIN #-} instance Functor T
>>  * Pros:
>>  - Backwards compatible
>>  - Requires no changes to Template Haskell
>>  * Cons:
>>  - Unlike other pragmas, these ones can affect the semantics of a program
>> - Type synonyms
>>  * Examples:
>>  - newtype T a = T a deriving (Builtin Eq, GND Ord, DAC Read, Show)
>>  - deriving instance Builtin (Functor T)
>>  * Pros:
>>  - Requires no Template Haskell or parser changes, just some
>> magic in the typechecker
>>  - Backwards compatible (back to GHC 7.6)
>>  * Cons:
>>  - Some developers objected to the idea of imbuing type synonyms
>> with magical properties
>> - Multiple deriving clauses, plus new keywords
>>  * Examples:
>>  - newtype T a = T a
>>  deriving Show
>>  deriving builtin instance (Eq, Foldable)
>>  deriving newtype instance Ord
>>  deriving anyclass instance Read
>>  - deriving builtin instance Functor T
>>  * Pros:
>>  - Doesn't suffer from the same semantic issues as the other suggestions
>>  - (Arguably) the most straightforward-looking syntax
>>  * Cons:
>>  - Requires breaking changes to Template Haskell
>>  - Changes the parser and syntax significantly
>> 
>> Several GHC devs objected to the first two of the above suggestions in
>> [1], so I chose to implement the "Multiple deriving clauses, plus new
>> keywords" option in [2]. However, I'd appreciate further discussion on
>> the above options, which one you prefer, and if you have other
>> suggestions for syntax to use.
>> 
>> Ryan S.
>> -
>> [1] https://ghc.haskell.org/trac/ghc/ticket/10598
>> [2] https://phabricator.haskell.org/D2280
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

— 
Moritz Angermann
+49 170 54 33 0 74
mor...@lichtzwerge.de

lichtzwerge GmbH
Raiffeisenstr. 8
93185 Michelsneukirchen

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

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

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

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  wrote:
> 
> I'm pursuing a fix to Trac #10598 [1], an issue in which GHC users do
> not have fine-grained control over which strategy to use when deriving
> an instance, especially when multiple extensions like
> -XGeneralizedNewtypeDeriving and -XDeriveAnyClass are enabled
> simultaneously. I have a working patch up at [2] which would fix the
> issue, but there's still a lingering question of what the right syntax
> is to use here. I want to make sure I get this right, so I'm
> requesting input from the community.
> 
> To condense the conversation in [1], there are three means by which
> you can derive an instance in GHC today:
> 
> 1. -XGeneralizedNewtypeDeriving
> 2. -XDeriveAnyClass
> 3. GHC's builtin algorithms (which are used for deriving Eq, Show,
> Functor, Generic, Data, etc.)
> 
> The problem is that it's sometimes hard to know which of the three
> will kick in when you say `deriving C`. To resolve this ambiguity, I
> want to introduce the -XDerivingStrategies extension, where a user can
> explicitly request which of the above ways to derive an instance.
> 
> Here are some of the previously proposed syntaxes for this feature,
> with their perceived pros and cons:
> 
> - Pragmas
>  * Examples:
>  - newtype T a = T a deriving ({-# BUILTIN #-} Eq, {-# GND #-}
> Ord, {-# DAC #-} Read, Show)
>  - deriving {-# BUILTIN #-} instance Functor T
>  * Pros:
>  - Backwards compatible
>  - Requires no changes to Template Haskell
>  * Cons:
>  - Unlike other pragmas, these ones can affect the semantics of a program
> - Type synonyms
>  * Examples:
>  - newtype T a = T a deriving (Builtin Eq, GND Ord, DAC Read, Show)
>  - deriving instance Builtin (Functor T)
>  * Pros:
>  - Requires no Template Haskell or parser changes, just some
> magic in the typechecker
>  - Backwards compatible (back to GHC 7.6)
>  * Cons:
>  - Some developers objected to the idea of imbuing type synonyms
> with magical properties
> - Multiple deriving clauses, plus new keywords
>  * Examples:
>  - newtype T a = T a
>  deriving Show
>  deriving builtin instance (Eq, Foldable)
>  deriving newtype instance Ord
>  deriving anyclass instance Read
>  - deriving builtin instance Functor T
>  * Pros:
>  - Doesn't suffer from the same semantic issues as the other suggestions
>  - (Arguably) the most straightforward-looking syntax
>  * Cons:
>  - Requires breaking changes to Template Haskell
>  - Changes the parser and syntax significantly
> 
> Several GHC devs objected to the first two of the above suggestions in
> [1], so I chose to implement the "Multiple deriving clauses, plus new
> keywords" option in [2]. However, I'd appreciate further discussion on
> the above options, which one you prefer, and if you have other
> suggestions for syntax to use.
> 
> Ryan S.
> -
> [1] https://ghc.haskell.org/trac/ghc/ticket/10598
> [2] https://phabricator.haskell.org/D2280
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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