Portable Pronounce
Torie Crivello
How about "maps to"? It's both succinct and arguably more technically accurate (i.e. no suggestion of a state change as with "goes to" or "becomes", no conflation of a set with its characteristic function as with "such that" or "for which") than the other alternatives. Though if there's already a standard as the MSDN page appears to imply, maybe you should just go with that (at least for C# code).
"Maps to" is my preferred pronunciation. Mathematically speaking, a function "maps" its arguments to its return value (one might even call the function a "mapping"), so it makes sense to me to use this terminology in programming, particularly as functional programming (especially the lambda calculus) is very close to mathematics. It's also more neutral than "becomes", "goes to", etc., since it doesn't suggest change of state, as contextfree mentioned.
I haven't thought it about much, but I just succintly say "to". It's short and concise, and implies that the variable is passed to the expression. I suppose it could be confused with the numeral 2 ("two"), but I tend to pronounce "to" more like "ta" when speaking. Nobody (who knows lambdas, at least) has ever told me they thought it ambiguous...
This is a great question if only for the bizarre answers. Most of the translations have other meanings than for lambda expressions, leading to exotic interpretations. As an old lambda-expression hacker, I just ignore the .NET notation and rewrite it as lambda in my head while wishing they had done almost anything else for this.
For narrating code over the phone, you want someone to be able to write the code down in sequence. That is a problem, of course, but lambda-arrow or something is probably the best you can get, or maybe lambda-in, but lambda-of is the most accurate.
I wouldn't use "such that" because that implies that the right hand side is a predicate that the left-hand side should satisfy. That is very different from talking about a right-hand side from which the left-hand side has been abstracted as a functional parameter. (The MSDN statement about "All lambda expressions" is simply offensive as well as inaccurate.)
Something rankles about "goes to" although it may be as close as we can get. "Goes to" implies a transformation, but there is not exactly some variable c that goes to an expression in c. The abstraction to a function is a little elusive. I could get accustomed to this, but I still yearn for something that emphasizes the abstraction of the variable.
Since the left-hand side is always a simple identifier in the cases used so far [but wait for extensions that may confuse this later on], I think for "c => expression" I would read "c 'lambda-function' expression"' or even "c 'arg' 'function' expression". In the last case, I could then say things like "b 'arg' c 'arg' 'function' expression".
I expect that the "goes-to" explanation will prevail simply because this is where a dominant majority is going to see lambda expressions for the first time. That's a pity. A good compromise might be "c 'lambda-of' e"
Apart from acquiring the preceding scope (all variables and constants that are in scope for a normal line of code at the point where a lambda expression occurs are available to the code of the expression) a lambda expression is essentially syntactic sugar for an inline function.
The list of values to the left of the production operator ("=>") contributes the structure and content of the stack frame used to make the call to this function. You could say that the list of values contributes both the parameter declarations and the arguments that are passed; in more conventional code these determine the structure and content of the stack frame used to make the call to a function.
In the narrowly defined application of boolean expressions used as filter conditions (a dominant use of lambda expressions extensively considered by other answers to this question) it is very reasonable to skip the method in favour of the intent of the code, and this leads to "for which" being just as succinct and saying more about the meaning of the code.
A crucial difference between explicitly passed parameters and captured variables (if I remember correctly - correct me if I'm wrong) is that the former are passed by reference and the latter by value.
When you grow up with an uncommon surname, mispronunciation is a lifelong companion. Doiron is a French name. There are lots of Franco-Americans in my home state of Maine. The name refers to the village of Oiron in the Poitou region of France. Long ago, one of my ancestors somehow acquired the surname d'Oiron. In the language of Michel de Montagne, Jean-Paul Sartre, and Maurice Chevalier this translates as "from the flyspeck of Oiron." Somewhere over the centuries, the apostrophe was misplaced, and we all became Doirons. I doubt it ever occurred to the original Monsieur d'Oiron that his American descendants would spend their lives suffering through endless mispronunciations of his elegant monicker.
In my life I've been called just about everything: Doron, Dyer, Drier, Dye-run, Dry-run. The most common variant was, and is, Dorian (as in Gray). The American tongue has difficulty wrapping itself around the French diphthong. I am sympathetic to this handicap although I sometimes wonder how Agatha Christie managed to create a world-famous Belgian detective with a surname almost identical to my own, and yet somehow hostesses in restaurants continue to page me as, "Darren, party of two."
So Hercule Poirot has been of no help. (Sometimes, I fancy that if ever I have a son I will name him Hercule. Either that or Elvis Aaron. One or the other.) The truth is I respond to nearly any sound that roughly approximates the six letters in my name. Shout Doo-run-run! and I'll know you mean me.
In fact, my name has been mispronounced so regularly, in so many different ways, that I have stopped bothering to correct people. What does it matter, after all? I know you bear me no malice when you call me "Paul Do-iron." That pronunciation isn't so far off the mark actually. I'll take it over most of the alternatives.
My first Atlassian Summit was last year. During a training event on day 1, the presenter introduced himself and then noted the class topic "JIRA / cunFLUence" Integration. I did a double take after hearing him say CONfluence like that. At first I thought he was trolling the class... I guess I have been pronouncing it incorrectly for 2 years.
Not to resurrect and old topic... but I heard it conFLUence today; instead of english dictionary style CONfluence. So I googled it and stumbled across this thread. Apparently, to each their own? Here is what YouTube and Text to Speech engines have to say about it: =4RvXWz2XW68
Matthew Stublefield? He's caught me out on a couple of odd intonations, but to be fair, I tend to say things like "Lurry" when trying to say "Lorry" and "cheese log" instead of "wood louse" - all down to where I grew up.
I mean, dictionary.com says it's Con-fluence (junction of two rivers), which is how I've always pronounced it. I don't recall hearing anyone at the last Atlassian Summit call it Cun-fluence either. Weird!
The "65 Roses" story dates back to 1965 when an observant 4-year-old, Richard "Ricky" Weiss, hearing the name of his disease for the first time, pronounced cystic fibrosis as "65 Roses." Today, "65 Roses" is a term often used by young children with cystic fibrosis to pronounce the name of their disease
You're invited to join the 65 Roses Club, a dedicated group of CF Foundation donors determined to help us find a cure for CF by providing a steady, reliable stream of support that enables the Foundation to fund highly innovative research and drug development, and provide high-quality, specialized care for people with CF.
This story begins in 1775 when Spanish Naval officer Bruno de Hezeta (or Heceta) y Dudagoitia left Spain as part of a small Spanish armada to sail to the military port of San Blas New Spain (Mexico). The Spanish government then sent Heceta northward to explore the Pacific Northwest and look for business opportunities to strengthen its claims to the region.
And here is where we reach the puzzle in this story. While following this narrative, how were you mentally pronouncing Heceta? Were you thinking it was Hay-SEE-ta, or Hay-ZEE-ta, or HECK-a-ta? Perhaps ay-THAY-ta, as it would be pronounced in Castilian?
In 1943, the Oregon Geographic Names Board (OGNB) began receiving letters from the U.S. Board on Geographic Names in Washington, D.C., because they also wanted to know the official pronunciation of Heceta. Over the course of a few months, the national board corresponded with people and agencies in Oregon, but no true conclusion was reached. U.S. Board on Geographic Names records document some of that correspondence.
On November 16, 1943, Burrill summed up the matter in a letter to realtor James A. Rodman, who had inquired about the pronunciation of Heceta Head as well as Willamette in a September 11, 1943, letter:
The name Heceta is frightfully mispronounced on some parts of the Oregon coast, where it is called Heketa, with a strong accent on the first syllable. In Castilian, the pronunciation would be Ay-Thay-tuh with the accent on the second syllable. This sounds a little difficult for Oregonians, most of whom seem to have Anglicized the word into Heseta, with the accent on the second syllable. Doubtless, that style will prevail.
Perhaps McArthur was right, but it should be noted that in Alaska, Heceta Island is pronounced HECK-ah-tah Island. I would say that the puzzle remains incomplete. Below we have included a few additional items from the U.S. Board on Geographic Names records that might be of interest for further reading.
On September 11, 1943, James A. Rodman wrote to Meredith Burrill of the U.S. Board on Geographic Names to ask for clarification on the pronunciation of Heceta Head and Willamette in Oregon. The letter appears to have initiated a flurry of correspondence that fall about the local pronunciation of Heceta Head.
c80f0f1006