Oleg Grenrus writes:

Should we test drive https://github.com/ghc-proposals/ghc-proposals 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 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 not, then no worries; we can continue here. Cheers, - Ben

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" wrote:

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 not, then no worries; we can continue here.

I hadn't thought of using ghc-proposals for this, and since it's still in a nascent state, I'll opt to continue using the GHC devs mailing list for this dicussion.

Alexey,

...

I can't see how this doesn't require changes to Template Haskell.

You are correct, I got my wires crossed when trying to recall the details. I think what I (sloppily) remembered was that in an earlier revision of https://phabricator.haskell.org/D2280, I had implemented a pragma-based approach that didn't require a language extension. But I now consider that a mistake, so I've introduced the -XDerivingStrategies extension, which should be required regardless of what syntax we decide to adopt.

Ryan S.

On Sun, Jul 17, 2016 at 6:36 AM, Ben Gamari wrote:

...

Oleg Grenrus writes:

...

Should we test drive https://github.com/ghc-proposals/ghc-proposals 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 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 not, then no worries; we can continue here.

Cheers,

- Ben

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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 Sunday, July 17, 2016, Ryan Scott wrote:

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 standard. (I don't know if that's the connotation you aimed for, but that's what I glean from reading it.) I want something that conveys the fact that when deriving this instance, GHC is using some domain-specific knowledge to derive the instance.

If not "builtin" or "standard", some other possibilities I can think of are "native", "original", or "specialized". I don't know if I have a strong preference for one in particular.

Another suggestion previously tossed around was "default", but I decided against that since that keyword is also used in -XDefaultSignatures, which very much has a generic programming connotation, and I didn't want users to confuse it with the -XDeriveAnyClass strategy.

Ryan S. ----- [1] http://git.haskell.org/ghc.git/blob/5df92f6776b31b375a80865e7db1f330d929c18f...

...

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" javascript:;> wrote:

...

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

...

...

...

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 not, then no worries; we can continue here.

I hadn't thought of using ghc-proposals for this, and since it's still in a nascent state, I'll opt to continue using the GHC devs mailing list for this dicussion.

Alexey,

...

I can't see how this doesn't require changes to Template Haskell.

You are correct, I got my wires crossed when trying to recall the details. I think what I (sloppily) remembered was that in an earlier revision of https://phabricator.haskell.org/D2280, I had implemented a pragma-based approach that didn't require a language extension. But I now consider that a mistake, so I've introduced the -XDerivingStrategies extension, which should be required regardless of what syntax we decide to adopt.

Ryan S.

On Sun, Jul 17, 2016 at 6:36 AM, Ben Gamari javascript:;> wrote:

...

Oleg Grenrus javascript:;> writes:

...

Should we test drive https://github.com/ghc-proposals/ghc-proposals 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 require it. Ryan, I'll leave

On Sun, Jul 17, 2016 at 8:59 AM, Elliot Cameron javascript:;> wrote: this 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 not, then no worries; we can continue here.

Cheers,

- Ben

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org javascript:; http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

---

ghc-devs mailing list ghc-devs@haskell.org javascript:; http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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, Jul 17, 2016 at 10:24 PM, Richard Eisenberg wrote:

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 is, one `deriving` clause where each element is optionally prefixed with a keyword. On the ticket (#10598), it is suggested that parsing these would be hard. I agree that parsing these would be annoying, but I do not think that they are actually ambiguous. Avoiding a few hours of pain in the parser should not be our motivation for choosing a syntax we will all live with for years. For `default` and `newtype`, parsing is actually easy. If we want to keep the `builtin` pseudo-keyword, we could always parse as a type and then have some non-parser code examine the resulting AST and sort it out. (This is done in several other dark corners of the parser already.)

Separately, I'm not enamored of the `builtin` keyword. The one idea I can suggest in this space (somewhat tongue-in-cheek, but feel free to take it seriously) is `bespoke` -- after all, each "builtin" instance must be generated by code written specifically for that class, which fits the English definition of bespoke nicely. "Which deriving mechanism do want?" "The bespoke one, please." And then GHC can boast that it has the classiest keyword of any programming language. :)

Richard

On Jul 16, 2016, at 10:02 PM, Ryan Scott wrote:

...

I'm pursuing a fix to Trac #10598 [1], an issue in which GHC users do not have fine-grained control over which strategy to use when deriving an instance, especially when multiple extensions like -XGeneralizedNewtypeDeriving and -XDeriveAnyClass are enabled simultaneously. I have a working patch up at [2] which would fix the issue, but there's still a lingering question of what the right syntax is to use here. I want to make sure I get this right, so I'm requesting input from the community.

To condense the conversation in [1], there are three means by which you can derive an instance in GHC today:

1. -XGeneralizedNewtypeDeriving 2. -XDeriveAnyClass 3. GHC's builtin algorithms (which are used for deriving Eq, Show, Functor, Generic, Data, etc.)

The problem is that it's sometimes hard to know which of the three will kick in when you say `deriving C`. To resolve this ambiguity, I want to introduce the -XDerivingStrategies extension, where a user can explicitly request which of the above ways to derive an instance.

Here are some of the previously proposed syntaxes for this feature, with their perceived pros and cons:

----- 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 * Cons: - Unlike other pragmas, these ones can affect the semantics of a program ----- Type synonyms * Examples: - newtype T a = T a deriving (Builtin Eq, GND Ord, DAC Read, Show) - deriving instance Builtin (Functor T) * Pros: - Requires no Template Haskell or parser changes, just some magic in the typechecker - Backwards compatible (back to GHC 7.6) * Cons: - Some developers objected to the idea of imbuing type synonyms with magical properties ----- Multiple deriving clauses, plus new keywords * Examples: - newtype T a = T a deriving Show deriving builtin instance (Eq, Foldable) deriving newtype instance Ord deriving anyclass instance Read - deriving builtin instance Functor T * Pros: - Doesn't suffer from the same semantic issues as the other suggestions - (Arguably) the most straightforward-looking syntax * Cons: - Requires breaking changes to Template Haskell - Changes the parser and syntax significantly

Several GHC devs objected to the first two of the above suggestions in [1], so I chose to implement the "Multiple deriving clauses, plus new keywords" option in [2]. However, I'd appreciate further discussion on the above options, which one you prefer, and if you have other suggestions for syntax to use.

Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/10598 [2] https://phabricator.haskell.org/D2280 _______________________________________________ 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

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 don't mind Richard's suggestion of using "bespoke". Another suggestion would be to use "magic".

I thought about verbosity here, and it's not clear which one is more verbose. For example, I frequently define a new newtype and then wish to use GND to derive a whole host of instances. In this case (is it common?), `deriving (X, Y) deriving newtype (A,B,C,D,E,F)` is shorter than putting newtype on each class name. I suppose we could provide both options, but that may be one bridge too far. Richard

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 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? :)

Please stop me if I've slipped into madness here.

We don't actually have to worry about keyword snatching, as there is no other lowercase word that can appear directly after `deriving`. We're happily in a new part of the grammar. On "bespoke": Pros: * It has precisely the right meaning * It's a fun word. (Fellow Americans, please update if this disagrees with your experience:) At least for Americans, for whom the word is instantly associated with spiffy haberdashery sold on Savile Row, London. It was actually quite a surprise to me when living in the UK that bespoke is used for other things as well. Example from my time there: I once went on a bespoke snowshoeing trip to France. Cons: * It's a fun word. People from those other languages with their boring OOP terms already think we're strange for having monoids and monads. Not to mention profunctors. What will they think of a bespoke Functor? I'm clearly enjoying this way too much.

Plus, on a superficial level, I like keeping the deriving strategy name outside of the parentheses. I think it makes clear that these keywords aren't modifying the type we're deriving, only the means by which we're deriving it. Of course, you may feel differently than I do, so please speak up if you disagree!

I actually agree here. This keeps all the keywords clustered together instead of interspersed with the more interesting bits. Richard

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 18, 2016 at 10:39 AM, Andres Loeh wrote:

...

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 "keyword" in the sense of reservedid, right?

...

...

I thought about verbosity here, and it's not clear which one is more verbose. For example, I frequently define a new newtype and then wish to use GND to derive a whole host of instances. In this case (is it common?), `deriving (X, Y) deriving newtype (A,B,C,D,E,F)` is shorter than putting newtype on each class name.

That's a good point. Another thing to consider is that I suspect in 90% of the time, users are only going to be reaching for -XDerivingStrategies in the scenario when they enable both -XGeneralizedNewtypeDeriving and -XDeriveAnyClass. That will happen when they want to derive instances for newtypes, and as you said, you typically derive several instances at a time when defining newtypes. Therefore, it seems less noisy to factor out the deriving strategy names so that readers can tell at a glance which batch of instances are newtype-derived and which are anyclass-derived, instead of having to read a keyword before every single type.

Yes, you've convinced me that putting the strategy once in front is at least not worse.

...

Plus, on a superficial level, I like keeping the deriving strategy name outside of the parentheses. I think it makes clear that these keywords aren't modifying the type we're deriving, only the means by which we're deriving it. Of course, you may feel differently than I do, so please speak up if you disagree!

The very first times when I've talked to others about this feature, I think I've always used "deriving (Eq via bespoke, Monad via gnd)" as syntax, but yes, in general I agree that keeping it completely out of the parentheses may be a mild advantage.

Cheers, Andres

Thanks for the feedback, everyone! I've typed up the developments so far in the DerivingStrategies Haskell wiki page [1]. Here's what seems to be the consensus: * The syntax in which actual keywords are used to designate deriving strategies was the clear favorite. * In particular, a slight edge goes to the form in which multiple deriving clauses can be placed after a datatype, and each `deriving` clause has its own (optional) strategy keyword, as opposed to putting the keyword directly in front of the derived type. * The `builtin` keyword was poorly received. There isn't a obvious candidate to replace it, and several of us like the word `bespoke`, so it looks like `bespoke` will be the replacement. (If someone ends up complaining about it, we've got several other choices.) Any other questions or comments? Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategies On Mon, Jul 18, 2016 at 5:54 PM, Simon Peyton Jones wrote:

I'm not following all the details here, and I do not feel strongly about syntax; but I do hope that you'll update the wiki page to reflect the discussion.

Thanks

Simon

-----Original Message----- From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Ryan Scott Sent: 18 July 2016 15:00 To: Richard Eisenberg Cc: Andres Loeh ; GHC developers Subject: 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 the outermost type in an instance declaration (unless we bake in a very prominent exception to this rule), and if we imbued type classes with this magic, one might think that "deriving (GND Eq)" means we're deriving an instance for the magical GND class, not Eq. So those approaches don't sound satisfying to me on a cursory examination.

Richard,

...

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 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? :)

Please stop me if I've slipped into madness here.

...

I thought about verbosity here, and it's not clear which one is more verbose. For example, I frequently define a new newtype and then wish to use GND to derive a whole host of instances. In this case (is it common?), `deriving (X, Y) deriving newtype (A,B,C,D,E,F)` is shorter than putting newtype on each class name.

That's a good point. Another thing to consider is that I suspect in 90% of the time, users are only going to be reaching for -XDerivingStrategies in the scenario when they enable both -XGeneralizedNewtypeDeriving and -XDeriveAnyClass. That will happen when they want to derive instances for newtypes, and as you said, you typically derive several instances at a time when defining newtypes. Therefore, it seems less noisy to factor out the deriving strategy names so that readers can tell at a glance which batch of instances are newtype-derived and which are anyclass-derived, instead of having to read a keyword before every single type.

Plus, on a superficial level, I like keeping the deriving strategy name outside of the parentheses. I think it makes clear that these keywords aren't modifying the type we're deriving, only the means by which we're deriving it. Of course, you may feel differently than I do, so please speak up if you disagree!

Ryan S. _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cea562a7e9e494f07cede08d3af13cbc7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=rKTWOkEZsKUdDOTnk7WL2BNx1lf36uelef4JDg0pX44%3d

Hi Simon,

* Current specification is here: ...

It's in a Haskell wiki page: [1]. This summarizes the current proposed syntax for -XDerivingStrategies, how GHC will choose a strategy in the absence of an explicit strategy, and also goes over some alternative syntaxes that have been proposed previously for the sake of archiving.

* Patch is here: ... (complete?)

It's on Phabricator: [2].

* Unresolved issues? Ready to review?

It's ready for review. It's incorporated all of the changes discussed on this e-mail thread, including renaming the "builtin" strategy to "bespoke", and including a link to the DerivingStrategies wiki in a Note. You left some inline comments on an earlier draft—I responded to some of them with questions [3], since I wasn't clear what you were asking. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategies [2] https://phabricator.haskell.org/D2280 [3] https://phabricator.haskell.org/D2280#inline-20129 On Thu, Aug 11, 2016 at 6:36 AM, Simon Peyton Jones wrote:

Ryan

I've been on holiday, and there's been a lot of traffic on this deriving-strategy thread.

Would you like to send an email summarising the state of play. Eg * Current specification is here: ... * Patch is here: ... (complete?) * Unresolved issues? Ready to review?

Thanks

Simon

| -----Original Message----- | From: Ryan Scott [mailto:ryan.gl.scott@gmail.com] | Sent: 02 August 2016 23:59 | To: Simon Peyton Jones | Cc: Richard Eisenberg ; Andres Loeh ; GHC developers | Subject: Re: Request for feedback: deriving strategies syntax | | Thanks for the feedback, everyone! I've typed up the developments so | far in the DerivingStrategies Haskell wiki page [1]. | | Here's what seems to be the consensus: | | * The syntax in which actual keywords are used to designate deriving | strategies was the clear favorite. | * In particular, a slight edge goes to the form in which multiple | deriving clauses can be placed after a datatype, and each `deriving` | clause has its own (optional) strategy keyword, as opposed to putting | the keyword directly in front of the derived type. | * The `builtin` keyword was poorly received. There isn't a obvious | candidate to replace it, and several of us like the word `bespoke`, so | it looks like `bespoke` will be the replacement. (If someone ends up | complaining about it, we've got several other choices.) | | | Any other questions or comments? | | Ryan S. | ----- | [1] | https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrate | gies | | On Mon, Jul 18, 2016 at 5:54 PM, Simon Peyton Jones | wrote: | > I'm not following all the details here, and I do not feel strongly | about syntax; but I do hope that you'll update the wiki page to reflect | the discussion. | > | > Thanks | > | > Simon | > | > -----Original Message----- | > From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Ryan | Scott | > Sent: 18 July 2016 15:00 | > To: Richard Eisenberg | > Cc: Andres Loeh ; GHC developers | > Subject: 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 the outermost type in an instance | declaration (unless we bake in a very prominent exception to this rule), | and if we imbued type classes with this magic, one might think that | "deriving (GND Eq)" means we're deriving an instance for the magical GND | class, not Eq. So those approaches don't sound satisfying to me on a | cursory examination. | > | > Richard, | > | >> 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 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? :) | > | > Please stop me if I've slipped into madness here. | > | >> I thought about verbosity here, and it's not clear which one is more | verbose. For example, I frequently define a new newtype and then wish to | use GND to derive a whole host of instances. In this case (is it | common?), `deriving (X, Y) deriving newtype (A,B,C,D,E,F)` is shorter | than putting newtype on each class name. | > | > That's a good point. Another thing to consider is that I suspect in | 90% of the time, users are only going to be reaching for - | XDerivingStrategies in the scenario when they enable both - | XGeneralizedNewtypeDeriving and -XDeriveAnyClass. That will happen when | they want to derive instances for newtypes, and as you said, you | typically derive several instances at a time when defining newtypes. | > Therefore, it seems less noisy to factor out the deriving strategy | names so that readers can tell at a glance which batch of instances are | newtype-derived and which are anyclass-derived, instead of having to | read a keyword before every single type. | > | > Plus, on a superficial level, I like keeping the deriving strategy | name outside of the parentheses. I think it makes clear that these | keywords aren't modifying the type we're deriving, only the means by | which we're deriving it. Of course, you may feel differently than I do, | so please speak up if you disagree! | > | > | > Ryan S. | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs@haskell.org | > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.has | kell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cea562a7e9e494f07c | ede08d3af13cbc7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=rKTWOkEZsKU | dDOTnk7WL2BNx1lf36uelef4JDg0pX44%3d

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 it in this context. I don't think "bespoken" is a synonym for "bespoke", at least according to Merriam-Webster, which claims that the modern-day definition of "bespoke" has a distinct meaning from "bespeak" (which "bespoken" is the past participle of) [1]. Disclaimer: I am not a linguist. :) 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 * wiredin * standard * native * original * specialized All of those suggestions sort of convey the meaning I want to evoke (i.e., derive an instance using some domain-specific knowledge to guide the implementation), but they all also have other connotations that could make them sound ambiguous. "Bespoke" at least has the advantage of being an obscure-enough word that I doubt anyone would accuse it of being misleading. 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. If folks strongly disagree, please chime in—I'm sure we can figure something that future deriving strategists can stomach. Ryan S. ----- [1] http://www.merriam-webster.com/dictionary/bespoke [2] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategies...

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 it in this context.

Oh dear. Please don't take my word for it. I (an American) do not use the word in my native lexicon but instead adopted it after living in England for several years. Would someone who uses this word natively (e.g., someone who has lived in England for more than several years) vouch for this usage? Richard

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 * wiredin * standard * native * original * specialized

Can we please just go with the obvious "builtin"? There's no need for willful obscurity here. 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 guess its meaning from context. I believe this is also the only context in which it's actually really used in British English. (However, I'll let the native (British) English speakers chime in on that.) Regards,

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 the term "bespoke suit" where you can sort-of guess its meaning from context. I believe this is also the only context in which it's actually really used in British English. (However, I'll let the native (British) English speakers chime in on that.)

"Bespoke" is a reasonably common British English word, used in all of the following phrases:

bespoke software bespoke solution bespoke furniture bespoke kitchen bespoke tailoring

The meaning is "specially and individually made for this client". The opposite of standard, off-the-shelf, pre-packaged. It implies the outcome was not automatable, even if the individual pieces being assembled were machine-cut.

Thanks, Mildly interestingly, both the online M-W and the online OED list only the clothing by example. (Though the definitions don't *preclude* any other type of goods.)

"In the U.S., bespoke software is often called custom or custom-designed software." http://whatis.techtarget.com/definition/bespoke

AFAIUI "custom", alas, doesn't really work in this context. :( Anyway, regardless of all that: "bespoke" is still a needlessly obscure word, IMO. Ergonomics matter in programming languages. Regards,