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