Request for feedback: deriving strategies syntax

Wed Sep 28 03:37:49 UTC 2016

With the "stock option" might I also suggest "OEM"? ;)

+1 stock

On Tue, Sep 27, 2016 at 10:06 PM, Richard Eisenberg <rae at cs.brynmawr.edu>
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 <ryan.gl.scott 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?
>
> A valid concern! Rest assured, you'd still be able to use "stock" as, say,
> a variable in a function, since GHC's parser has a production just for IDs
> that have meanings in special contexts. (If you want to win at Haskell
> trivia night, the current special IDs are "as", "qualified", "hiding",
> "export", "label", "dynamic", "stdcall", "ccall", "capi", "prim",
> "javascript", and "group" [1]). In my implementation, I make "stock" and
> "anyclass" special IDs, so they only become keywords when used after
> "deriving".
>
> Ryan S.
> -----
> [1] http://git.haskell.org/ghc.git/blob/f897b7427a4804e3285144f5767657
> 4d338be1f5:/compiler/parser/Parser.y#l3054
> [2]
>
> On Wed, Sep 28, 2016 at 8:49 AM, Carter Schonwald <
> carter.schonwald 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
>>>
>>>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160927/5c37c6f4/attachment-0001.html>