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