+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/f897b7427a4804e3285144f57676574d338be1f5:/compiler/parser/Parser.y#l3054 > > <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 > <mailto: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 > <mailto: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 > <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 > <mailto: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 <mailto:ghc-devs@haskell.org> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
