Come posso pronunciare "=>" come usato nelle espressioni lambda in .Net

Molto raramente incontro altri programmatori!

Il mio pensiero quando ho visto il token per la prima volta era "implica che" poiché è quello che lo avrebbe letto come in una prova matematica, ma chiaramente non ha senso.

Quindi, come posso dire o leggere "=>" come in: -

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

O esiste un modo concordato per dirlo?

Di solito dico "tale" quando leggo quell'operatore.

Nel tuo esempio, p => p.Age> 16 è "P, tale che p.Age è maggiore di 16."

In effetti, ho posto questa domanda sui forum pre-release ufficiali di linq e Anders Hejlsberg ha risposto dicendo

Di solito leggo l'operatore => come "diventa" o "per cui". Ad esempio,
Func f = x => x * 2;
Func test = c => c.City == "London";
legge "x diventa x * 2" e "c per cui c.City è uguale a Londra"

Per quanto riguarda "va a", non ha mai avuto senso per me. 'p' non sta andando da nessuna parte.

Nel caso di leggere il codice a qualcuno, diciamo, per telefono, quindi fintanto che sono un collega programmatore C #, userò semplicemente la parola "lambda", cioè "p lambda p dot age maggiore di sedici."

Nei commenti Steve Jessop ha menzionato "mappe a" nel caso delle trasformazioni, prendendo così l'esempio di Anders:

x => x * 2;

leggerebbe

x è mappato a x volte 2.

Ciò sembra molto più vicino all'intenzione reale del codice che "diventa" per questo caso.

Da MSDN :

Tutte le espressioni lambda usano l'operatore lambda =>, che viene letto come "va a".

Lettura del codice al telefono

Da Eric Lippert:

Personalmente direi c => c + 1 come "vedi va vedere più uno". Alcune variazioni che ho sentito:

Per una proiezione, (Cliente c) => c.Name: "cliente vedere diventa vedere nome punto"

Per un predicato, (Cliente c) => c.Age> 21: "il cliente vede tale che vedere l'età dei punti è maggiore di ventuno"

L'ho sempre chiamato "operatore wang" :-)

"età p maggiore di 16 anni"

Ho visto persone dire "Freccia".

Uso "va a" perché un libro LINQ mi ha detto di :)

Che ne dici di "mappe per"? È sia sintetico che discutibilmente più tecnicamente accurato (cioè nessun suggerimento di un cambio di stato come con "va a" o "diventa", nessuna conflazione di un insieme con la sua funzione caratteristica come con "tale che" o "per cui") rispetto al altre alternative. Sebbene se c'è già uno standard come sembra implicare la pagina MSDN, forse dovresti semplicemente andare con quello (almeno per il codice C #).

"Maps to" è la mia pronuncia preferita. Matematicamente parlando, una funzione "mappa" i suoi argomenti al suo valore di ritorno (si potrebbe persino chiamare la funzione una "mappatura"), quindi per me ha senso usare questa terminologia nella programmazione, in particolare come programmazione funzionale (specialmente il calcolo lambda) è molto vicino alla matematica. È anche più neutrale di "diventa", "va a", ecc., Poiché non suggerisce un cambio di stato, come menzionato senza contesto.

Non ci ho pensato molto, ma dico semplicemente "a". E 'breve e conciso, e implica che la variabile viene passata al l'espressione. Suppongo che potrebbe essere confuso con il numero 2 ("due"), ma tendo a pronunciare "a" più come "ta" quando si parla. Nessuno (che conosce almeno i lambda) mi ha mai detto di aver pensato che fosse ambiguo ...

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

La mia breve risposta: "c 'lambda-di' e". Sebbene mi aggrappi a "'lambda' c 'function' e", penso che lambda-of sia il compromesso ecumenico. Segue l'analisi.

Questa è un'ottima domanda se non altro per le risposte bizzarre. La maggior parte delle traduzioni ha altri significati rispetto alle espressioni lambda, portando a interpretazioni esotiche. Come un vecchio hacker di espressioni lambda, ignoro semplicemente la notazione .NET e la riscrivo come lambda nella mia testa, desiderando che avessero fatto quasi qualsiasi altra cosa per questo.

Per narrare il codice al telefono, vuoi che qualcuno sia in grado di scrivere il codice in sequenza. Questo è un problema, ovviamente, ma lambda-freccia o qualcosa è probabilmente il migliore che puoi ottenere, o forse lambda-in, ma lambda-of è il più preciso.

Il problema è l'uso dell'infisso e come nominare l'intera cosa e il ruolo delle parti sinistra e destra con qualcosa che funziona quando viene parlato al posto dell'infisso.

Questo potrebbe essere un problema troppo limitato!

Non userei "tale" perché ciò implica che il lato destro è un predicato che il lato sinistro dovrebbe soddisfare. Questo è molto diverso dal parlare di un lato destro da cui il lato sinistro è stato sottratto come parametro funzionale. (L'affermazione MSDN su "Tutte le espressioni lambda" è semplicemente offensiva e inaccurata.)

Qualcosa di "va a" anche se può essere il più vicino possibile. "Va a" implica una trasformazione, ma non esiste esattamente una variabile c che vada a un'espressione in c. L'astrazione per una funzione è un po 'sfuggente. Potrei abituarmi a questo, ma desidero ancora qualcosa che enfatizzi l'astrazione della variabile.

Dato che il lato sinistro è sempre un semplice identificatore nei casi utilizzati finora [ma aspetto estensioni che potrebbero confonderlo in seguito], penso che "c => espressione" leggerei "c 'funzione lambda-funzione" "'o anche" c' arg '' funzione 'espressione ". Nell'ultimo caso, potrei quindi dire cose come "b 'arg' c 'arg' 'funzione' espressione".

Potrebbe essere meglio chiarire che viene introdotta un'espressione lambda e dire qualcosa come "espressione '' arg 'b' arg 'c' function ''.

Capire come tradurre tutto questo in altre lingue è un esercizio per lo studente [; <).

Mi preoccupo ancora di "(b, c) => espressione" e di altre varianti che potrebbero nascere se non lo sono già. Forse "'args' b, c 'funzione' espressione".

Dopo tutto questo riflettere, noto che sto arrivando a tradurre "c => e" come "'lambda' c 'function' e" e notando che la mappatura alla forma esatta deve essere compresa dal contesto: λc (e ), c => e, f dove f (c) = e, ecc.

Mi aspetto che la spiegazione del "go to to" prevarrà semplicemente perché è qui che la maggioranza dominante vedrà le espressioni lambda per la prima volta. È un peccato. Un buon compromesso potrebbe essere "c ' lambda-of ' e"

Se immagini un'espressione lambda come metodo anonimo, "va a" ha abbastanza senso.

(n => n == String.Empty)

n "va a" l'espressione n == String.Empty.

Va al metodo anonimo, quindi non devi andare al metodo nel codice!

Scusa per quello.

Onestamente, non mi piace usare "va a" nella mia testa, ma ho visto altre persone dire che sembrava strano, e ho pensato di chiarirlo.

Oltre ad acquisire l'ambito precedente (tutte le variabili e le costanti che sono nell'ambito di una normale riga di codice nel punto in cui si verifica un'espressione lambda sono disponibili per il codice dell'espressione) un'espressione lambda è essenzialmente zucchero sintattico per una funzione inline.

L'elenco di valori a sinistra dell'operatore di produzione ("=>") contribuisce alla struttura e al contenuto del frame dello stack utilizzato per effettuare la chiamata a questa funzione. Si potrebbe dire che l'elenco dei valori contribuisce sia alle dichiarazioni dei parametri sia agli argomenti che vengono passati; nel codice più convenzionale determinano la struttura e il contenuto del frame dello stack utilizzato per effettuare la chiamata a una funzione.

Di conseguenza, i valori "vanno a" il codice dell'espressione. Preferiresti dire "definisce il frame dello stack per" o "va a"? :)

Nell'applicazione strettamente definita delle espressioni booleane utilizzate come condizioni di filtro (un uso dominante delle espressioni lambda ampiamente considerato da altre risposte a questa domanda) è molto ragionevole saltare il metodo a favore dell'intento del codice e questo porta a " per cui "essere altrettanto concisi e dire di più sul significato del codice.

Tuttavia, le espressioni lambda non sono l'unica provincia di Linq e al di fuori di questo contesto dovrebbe essere usata la forma più generale "va a".

Ma perché "va a"?

Perché "popola il frame dello stack del seguente codice" è troppo lungo per continuare a dirlo. Suppongo che potresti dire "è / sono passato a".

Una differenza cruciale tra parametri passati esplicitamente e variabili acquisite (se ricordo bene, correggimi se sbaglio) è che i primi sono passati per riferimento e i secondi per valore.

Parte del problema è che puoi leggerlo ad alta voce in modo diverso a seconda di come è strutturato. È un peccato che non sia così bello o integrato come quello di Ruby.

In Ruby, questo stesso sybmol si chiama "hashrocket" e ho sentito che anche i programmatori C # usano quel termine (anche se farlo è sbagliato).

I miei due centesimi:

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

"Espressione lambda con parametro s è { return s.Age > 12 && s.Age < 20;}"

Mi piace perché mi ricorda da dove viene l'espressione lamdba

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

=> è solo una scorciatoia, quindi non è necessario utilizzare la parola chiave delegata e includere le informazioni sul tipo poiché può essere dedotto dal compilatore.

Il mio termine per => applicato agli esempi mostrati risulta

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

s dove s.Age è maggiore di 12 e s.Age meno di 20

'result = x => x * 2'

x dove x viene moltiplicato per 2

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

c dove c.city è equivalente a "London"

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

n dove n è una stringa vuota