Re: Request for feedback: deriving strategies syntax

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

Re: Request for feedback: deriving strategies syntax

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 >

Re: Request for feedback: deriving strategies syntax

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

Re: Request for feedback: deriving strategies syntax

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 :

Re: Request for feedback: deriving strategies syntax

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"

Re: Request for feedback: deriving strategies syntax

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

Re: Request for feedback: deriving strategies syntax

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

Re: Request for feedback: deriving strategies syntax

(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

Re: Request for feedback: deriving strategies syntax

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.

Re: Request for feedback: deriving strategies syntax

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

Re: Request for feedback: deriving strategies syntax

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

Re: Request for feedback: deriving strategies syntax

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]) > *

Re: Request for feedback: deriving strategies syntax

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

Re: Request for feedback: deriving strategies syntax

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".

Re: Request for feedback: deriving strategies syntax

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 <

Re: Request for feedback: deriving strategies syntax

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

Re: Request for feedback: deriving strategies syntax

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

Re: Request for feedback: deriving strategies syntax

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

RE: Request for feedback: deriving strategies syntax

C 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 co

Re: Request for feedback: deriving strategies syntax

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

Re: Request for feedback: deriving strategies syntax

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 > *

Re: Request for feedback: deriving strategies syntax

> 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

Re: Request for feedback: deriving strategies syntax

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.

Re: Request for feedback: deriving strategies syntax

gt; | 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>

RE: Request for feedback: deriving strategies syntax

t; 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 | >

Re: Request for feedback: deriving strategies syntax

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

Re: Request for feedback: deriving strategies syntax

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

Re: Request for feedback: deriving strategies syntax

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

Re: Request for feedback: deriving strategies syntax

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]

Re: Request for feedback: deriving strategies syntax

> 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

Re: Request for feedback: deriving strategies syntax

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

Re: Request for feedback: deriving strategies syntax

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

Re: Request for feedback: deriving strategies syntax

> 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

Re: Request for feedback: deriving strategies syntax

> 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

Re: Request for feedback: deriving strategies syntax

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,

Re: Request for feedback: deriving strategies syntax

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

Re: Request for feedback: deriving strategies syntax

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].

Re: Request for feedback: deriving strategies syntax

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

Re: Request for feedback: deriving strategies syntax

> 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-dev

RE: Request for feedback: deriving strategies syntax

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

Re: Request for feedback: deriving strategies syntax

> 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

Re: Request for feedback: deriving strategies syntax

> 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

Re: Request for feedback: deriving strategies syntax

> 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

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

Re: Request for feedback: deriving strategies syntax

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

Re: Request for feedback: deriving strategies syntax

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

Re: Request for feedback: deriving strategies syntax

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

Re: Request for feedback: deriving strategies syntax

> 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

Re: Request for feedback: deriving strategies syntax

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

Re: Request for feedback: deriving strategies syntax

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

Re: Request for feedback: deriving strategies syntax

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"

Re: Request for feedback: deriving strategies syntax

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

Re: Request for feedback: deriving strategies syntax

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

Re: Request for feedback: deriving strategies syntax

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

Re: Request for feedback: deriving strategies syntax

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

Re: Request for feedback: deriving strategies syntax

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