Wie spreche ich "=>" aus, wie es in Lambda-Ausdrücken in .Net verwendet wird?

Ich treffe sehr selten andere Programmierer!

Mein Gedanke, als ich das Token zum ersten Mal sah, war "impliziert das", da es so wie in einem mathematischen Beweis gelesen würde, aber das ist eindeutig nicht sein Sinn.

Wie sage oder lese ich "=>" wie in: -

IEnumerable<Person> Adults = people.Where(p => p.Age > 16)

Oder gibt es überhaupt eine vereinbarte Art, es zu sagen?

Normalerweise sage ich "so dass", wenn ich diesen Operator lese.

In Ihrem Beispiel lautet p => p.Age> 16 "P, sodass p.Age größer als 16 ist."

Tatsächlich habe ich genau diese Frage in den offiziellen linq Pre-Release-Foren gestellt, und Anders Hejlsberg antwortete mit den Worten

Normalerweise lese ich den Operator => als "wird" oder "für welche". Zum Beispiel ist
Func f = x => x * 2;
Func test = c => c.City == "London";
liest als "x wird x * 2" und "c, für die c.City gleich London ist"

Soweit es geht - das hat für mich nie Sinn gemacht. 'p' geht nirgendwo hin.

Wenn ich jemandem Code vorlese, beispielsweise telefonisch, vorlese, würde ich, solange er ein C # -Programmierer ist, einfach das Wort "Lambda" verwenden - das heißt "p lambda p dot age größer als" Sechszehn."

In Kommentaren erwähnte Steve Jessop 'Maps to' im Fall von Transformationen - also am Beispiel von Anders:

x => x * 2;

würde lesen

x ist x mal 2 zugeordnet.

Das scheint der tatsächlichen Absicht des Codes viel näher zu sein, als es für diesen Fall "wird".

Von MSDN :

Alle Lambda-Ausdrücke verwenden den Lambda-Operator =>, der als "geht nach" gelesen wird.

Code über das Telefon lesen

Von Eric Lippert:

Ich persönlich würde c => c + 1 als "sehen geht, um plus eins zu sehen" sagen. Einige Variationen, die ich gehört habe:

Für eine Projektion gilt (Kunde c) => c.Name: "Kunde sieht wird Punktname sehen"

Für ein Prädikat gilt (Kunde c) => c.Age> 21: "Kunde sieht so, dass das Punktalter größer als einundzwanzig ist"

Ich habe es immer den "Wang Operator" genannt :-)

"p wang Alter von p größer als 16"

Ich habe Leute sagen sehen: "Pfeil."

Ich benutze "geht zu", weil mir ein LINQ-Buch gesagt hat :)

Wie wäre es mit "Karten zu"? Es ist sowohl prägnant als auch technisch genauer (dh kein Hinweis auf eine Zustandsänderung wie bei "geht zu" oder "wird", keine Verschmelzung einer Menge mit ihrer charakteristischen Funktion wie bei "so dass" oder "für welche") als die andere Alternativen. Wenn es bereits einen Standard gibt, wie die MSDN-Seite zu implizieren scheint, sollten Sie dies vielleicht einfach tun (zumindest für C # -Code).

"Maps to" ist meine bevorzugte Aussprache. Mathematisch gesehen "ordnet" eine Funktion ihre Argumente ihrem Rückgabewert zu (man könnte die Funktion sogar als "Mapping" bezeichnen), daher ist es für mich sinnvoll, diese Terminologie in der Programmierung zu verwenden, insbesondere als funktionale Programmierung (insbesondere als Lambda-Kalkül). ist sehr nah an der Mathematik. Es ist auch neutraler als "wird", "geht zu" usw., da es, wie im Kontext erwähnt, keine Änderung des Zustands nahe legt.

Ich habe nicht viel darüber nachgedacht, aber ich sage nur kurz und bündig "zu". Es ist kurz und prägnant und impliziert, dass die Variable an den Ausdruck übergeben wird. Ich nehme an, es könnte mit der Ziffer 2 ("zwei") verwechselt werden, aber ich neige dazu, "zu" eher wie "ta" auszusprechen, wenn ich spreche. Niemand (der zumindest Lambdas kennt) hat mir jemals gesagt, dass er es für mehrdeutig hält ...

// "Func f equals x to x times two"
Func f = x=> x * 2;

// "Func test equals c to c dot City equals London"
Func test = c => c.City == "London"

Meine kurze Antwort: "c 'lambda-of' e". Obwohl ich mich an "Lambda 'c' Funktion 'e" klammere, denke ich, dass Lambda-of der ökumenische Kompromiss ist. Die Analyse folgt.

Dies ist eine großartige Frage, wenn auch nur für die bizarren Antworten. Die meisten Übersetzungen haben andere Bedeutungen als für Lambda-Ausdrücke, was zu exotischen Interpretationen führt. Als alter Hacker mit Lambda-Ausdruck ignoriere ich einfach die .NET-Notation und schreibe sie als Lambda in meinem Kopf um, während ich wünschte, sie hätten fast alles andere dafür getan.

Wenn Sie Code über das Telefon erzählen möchten, möchten Sie, dass jemand den Code nacheinander aufschreiben kann. Das ist natürlich ein Problem, aber Lambda-Pfeil oder so ist wahrscheinlich das Beste, was man bekommen kann, oder vielleicht Lambda-In, aber Lambda-Of ist das genaueste.

Das Problem ist die Verwendung von Infixen und wie man das Ganze und die Rolle des linken und rechten Teils mit etwas benennt, das funktioniert, wenn es an der Infixstelle gesprochen wird.

Dies kann ein übermäßiges Problem sein!

Ich würde "so dass" nicht verwenden, da dies impliziert, dass die rechte Seite ein Prädikat ist, das die linke Seite erfüllen sollte. Das unterscheidet sich sehr von einer rechten Seite, von der die linke Seite als Funktionsparameter abstrahiert wurde. (Die MSDN-Aussage zu "Alle Lambda-Ausdrücke" ist einfach beleidigend und ungenau.)

Etwas rangiert an "geht zu", obwohl es so nah wie möglich sein kann. "Geht zu" impliziert eine Transformation, aber es gibt nicht genau eine Variable c, die zu einem Ausdruck in c geht. Die Abstraktion zu einer Funktion ist etwas schwer fassbar. Ich könnte mich daran gewöhnen, aber ich sehne mich immer noch nach etwas, das die Abstraktion der Variablen betont.

Da die linke Seite in den bisher verwendeten Fällen immer eine einfache Kennung ist [aber auf Erweiterungen warten, die dies später verwirren könnten], würde ich für "c => Ausdruck" den Ausdruck "c 'Lambda-Funktion' lesen "'oder sogar" c' arg '' Funktionsausdruck ". Im letzten Fall könnte ich dann Dinge wie "b 'arg' c 'arg' 'Funktionsausdruck" sagen.

Es könnte besser sein, noch deutlicher zu machen, dass ein Lambda-Ausdruck eingeführt wird, und so etwas wie "arg 'b' arg 'c' function 'expression" zu sagen.

Herauszufinden, wie all dies in andere Sprachen übersetzt werden kann, ist eine Übung für den Schüler [; <).

Ich mache mir immer noch Sorgen um "(b, c) => Ausdruck" und andere Varianten, die entstehen könnten, wenn sie es noch nicht getan haben. Vielleicht "'args' b, c 'function' expression".

Nach all diesen Überlegungen bemerke ich, dass ich "c => e" als "'Lambda' c 'Funktion' e" übersetze und bemerke, dass die Zuordnung zur exakten Form unter dem Kontext zu verstehen ist: λc (e ), c => e, f wo f (c) = e usw.

Ich gehe davon aus, dass sich die "go-to" -Erklärung einfach durchsetzen wird, weil hier eine dominante Mehrheit zum ersten Mal Lambda-Ausdrücke sehen wird. Das ist schade. Ein guter Kompromiss könnte "c ' lambda-of ' e" sein.

Wenn Sie sich einen Lambda-Ausdruck als die anonyme Methode vorstellen, die er ist, macht "geht zu" ausreichend Sinn.

(n => n == String.Empty)

n "geht zu" dem Ausdruck n == String.Empty.

Es geht zur anonymen Methode, so dass Sie nicht zur Methode im Code gehen müssen!

Das tut mir leid.

Ehrlich gesagt, ich mag es nicht, "geht zu" in meinem Kopf zu verwenden, aber ich sah andere Leute sagen, dass es seltsam schien, und ich dachte, ich würde das klären.

Abgesehen vom Erfassen des vorhergehenden Bereichs (alle Variablen und Konstanten, die für eine normale Codezeile an dem Punkt gelten, an dem ein Lambda-Ausdruck auftritt, stehen dem Code des Ausdrucks zur Verfügung) ist ein Lambda-Ausdruck im Wesentlichen syntaktischer Zucker für eine Inline-Funktion.

Die Werteliste links vom Produktionsoperator ("=>") trägt zur Struktur und zum Inhalt des Stapelrahmens bei, mit dem diese Funktion aufgerufen wird. Man könnte sagen, dass die Liste der Werte sowohl die Parameterdeklarationen als auch die übergebenen Argumente enthält. In herkömmlicherem Code bestimmen diese die Struktur und den Inhalt des Stapelrahmens, der zum Aufrufen einer Funktion verwendet wird.

Infolgedessen "gehen" die Werte zum Ausdruckscode. Möchten Sie lieber sagen "definiert den Stapelrahmen für" oder "geht zu"? :) :)

In der eng definierten Anwendung von Booleschen Ausdrücken, die als Filterbedingungen verwendet werden (eine dominante Verwendung von Lambda-Ausdrücken, die in anderen Antworten auf diese Frage ausführlich berücksichtigt wird), ist es sehr vernünftig, die Methode zugunsten der Absicht des Codes zu überspringen, und dies führt zu " wofür "genauso prägnant sein und mehr über die Bedeutung des Codes sagen.

Lambda-Ausdrücke sind jedoch nicht die einzige Provinz von Linq, und außerhalb dieses Kontextes sollte die allgemeinere Form "geht zu" verwendet werden.

Aber warum "geht zu"?

Weil "den Stapelrahmen des folgenden Codes auffüllt" viel zu lang ist, um es immer wieder zu sagen. Ich nehme an, Sie könnten sagen "wird / werden weitergegeben".

Ein entscheidender Unterschied zwischen explizit übergebenen Parametern und erfassten Variablen (wenn ich mich richtig erinnere - korrigiere mich, wenn ich falsch liege) besteht darin, dass erstere als Referenz und letztere als Wert übergeben werden.

Ein Teil des Problems ist, dass Sie es je nach Struktur unterschiedlich laut vorlesen können. Es ist eine Schande, dass es nicht so hübsch oder integriert ist wie das von Ruby.

In Ruby heißt dasselbe Sybmol "Hashrocket", und ich habe gehört, dass C # -Programmierer diesen Begriff ebenfalls verwenden (obwohl dies falsch ist).

Meine zwei Cent:

s => s.Age > 12 && s.Age < 20

"Lambda-Ausdruck mit Parameter s ist { return s.Age > 12 && s.Age < 20;}"

Ich mag das, weil es mich daran erinnert, woher der Lamdba-Ausdruck kommt

delegate(Student s) { return s.Age > 12 && s.Age < 20; };

=> ist nur eine Verknüpfung, sodass Sie nicht das Schlüsselwort delegate verwenden und die Typinformationen einschließen müssen, da diese vom Compiler abgeleitet werden können.

Mein Begriff für => für die gezeigten Beispiele ergibt sich

'result = s => s.Age > 12 && s.Age < 20'

s wobei s.Age größer als 12 und s.Age kleiner als 20 ist

'result = x => x * 2'

x wobei x mit 2 multipliziert wird

'result = c => c.City == "London"'

c wobei c.city "London" entspricht

'result = n => n == String.Empty'

n wobei n eine leere Zeichenfolge ist