Come si pronuncia “=>” come usato nelle espressioni lambda in .Net

Raramente incontro altri programmatori!

Il mio pensiero quando ho visto per la prima volta il token è stato “implica quello” poiché è quello che leggerà come in una dimostrazione matematica ma che chiaramente non è il suo senso.

Quindi, come faccio a dire o leggere “=>” come in: –

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

O c’è persino un modo concordato per dirlo?

Di solito dico “così” quando leggo quell’operatore.

Nel tuo esempio, p => p.ge> 16 si legge come “P, tale che p.ge è maggiore di 16.”

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

Di solito leggo l’operatore => come “diventa” o “per il quale”. Per esempio,
Func f = x => x * 2;
Func test = c => c.City == “London”;
legge come “x diventa x * 2” e “c per cui c.City equivale 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, per esempio, per telefono, finché sono un programmatore C #, utilizzerei semplicemente la parola “lambda” – cioè “p lambda p punto age” sedici.”

Nei commenti Steve Jessop ha citato “mappe” nel caso di trasformazioni, quindi prendendo l’esempio di Anders:

 x => x * 2; 

leggerebbe

x mappe per x volte 2.

Sembra molto più vicino alla reale intenzione del codice di “diventare” per questo caso.

Da MSDN :

Tutte le espressioni lambda utilizzano l’operatore lambda =>, che viene letto come “va a”.

Codice di lettura tramite telefono

Da Eric Lippert:

Personalmente direi c => c + 1 come “vedi va a vedere più uno”. Alcune varianti che ho sentito:

Per una proiezione, (Cliente c) => c.Nome: “il cliente vede diventa vedere il nome del punto”

Per un predicato, (Cliente c) => c.Età> 21: “il cliente vede tale che vedere punto età è maggiore di ventuno”

L’ho sempre chiamato “operatore wang” 🙂

“p wang age of p maggiore di 16”

Ho visto persone dire “Arrow”.

Uso “va a” perché un libro LINQ mi ha detto di 🙂

Che ne dici di “mappe per”? È sia succinto che probabilmente più accurato dal punto di vista tecnico (ovvero nessun suggerimento di un cambiamento di stato come con “va a” o “diventa”, nessuna fusione di un insieme con la sua funzione caratteristica come “tale che” o “per cui”) altre alternative. Anche se c’è già uno standard come la pagina MSDN sembra implicare, 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 anche chiamare la funzione “mapping”), quindi ha senso usare questa terminologia in 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 il cambiamento di stato, come menzionato senza contesto.

Non ci ho pensato molto, ma dico succintamente “a”. È breve e conciso e implica che la variabile sia passata all’espressione. Suppongo che potrebbe essere confuso con il numero 2 (“due”), ma io tendo a pronunciare “a” più come “ta” quando si parla. Nessuno (che almeno conosce i lambda) mi ha mai detto che lo ritenevano 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 risposta breve: “c ‘lambda-of’ e”. Anche se mi sto aggrappando a “‘lambda’ c ‘function’ e”, penso che lambda-of sia il compromesso ecumenico. L’analisi segue.

Questa è una grande domanda, se non altro per le risposte bizzarre. La maggior parte delle traduzioni ha altri significati che per le espressioni lambda, che portano a interpretazioni esotiche. Come un vecchio hacker di espressione lambda, ignoro semplicemente la notazione .NET e la riscrivo come lambda nella mia testa mentre mi auguro che abbiano fatto quasi tutto il resto 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-arrow o qualcosa è probabilmente il meglio che puoi ottenere, o forse lambda-in, ma lambda-of è il più preciso.

Il problema è l’utilizzo di infisso e come nominare l’intera cosa e il ruolo delle parti sinistra e destra con qualcosa che funziona quando si parla nel punto infisso.

Questo potrebbe essere un problema troppo vincolante!


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 dal quale il lato sinistro è stato astratto come parametro funzionale. (L’istruzione MSDN su “Tutte le espressioni lambda” è semplicemente offensiva e imprecisa.)

Qualcosa va in giro per “va” anche se potrebbe essere il più vicino ansible. “Goes to” implica una trasformazione, ma non esiste esattamente una variabile c che vada a un’espressione in c. L’astrazione di una funzione è un po ‘sfuggente. Potrei abituarmi a questo, ma desidero ancora qualcosa che enfatizzi l’astrazione della variabile.

Dal momento che il lato sinistro è sempre un semplice identificatore nei casi utilizzati finora [ma attendo estensioni che potrebbero confonderlo più avanti], penso che per “c => espressione” vorrei leggere “c espressione ‘lambda-function’ “‘o anche’ c ‘arg’ ‘funzione’ espressione”. Nell’ultimo caso, potrei quindi dire cose come “b ‘arg’ c ‘arg’ ‘function’ espressione”.

Potrebbe essere meglio rendere ancora più chiaro che viene introdotta un’espressione lambda e pronunciare qualcosa come “‘arg’ b ‘arg’ c ‘funzione’ espressione”.

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 l’hanno già fatto. Forse “‘args’ b, c ‘funzione’ espressione”.


Dopo aver riflettuto su tutto ciò, noto che sto arrivando a tradurre “c => e” come “‘lambda’ c ‘function’ e” e notare che la mapping per la 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” prevarrà semplicemente perché è qui che la maggioranza dominante vedrà per la prima volta espressioni lambda. È un peccato. Un buon compromesso potrebbe essere “c ‘ lambda-of ‘ e”

Se immaginate un’espressione lambda come il metodo anonimo che è, “passa a” ha abbastanza senso.

 (n => n == String.Empty) 

n “passa a” l’espressione n == String.Empty.

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

Perdonami per quello.

Onestamente, non mi piace usare “va a” nella mia testa, ma ho visto altre persone dire che sembrava strano, e ho pensato che avrei chiarito.

Oltre all’acquisizione dell’ambito precedente (tutte le variabili e le costanti che rientrano 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 di valori contribuisca sia alle dichiarazioni dei parametri sia agli argomenti che vengono passati; nel codice più convenzionale questi determinano la struttura e il contenuto del frame dello stack usato per effettuare la chiamata a una funzione.

Di conseguenza, i valori “vanno a” il codice di espressione. Preferiresti dire “definisce lo stack frame per” o “va a”? 🙂

Nell’applicazione strettamente definita di espressioni booleane usate come condizioni di filtro (un uso dominante di espressioni lambda ampiamente considerate 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 succinti 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 lo stack frame del seguente codice” è troppo lungo per continuare a dirlo. Suppongo che tu possa dire “è / sono passato a”.

Una differenza cruciale tra i parametri esplicitamente passati e le variabili catturate (se ricordo bene – correggimi se sbaglio) è che i primi sono passati per riferimento e il secondo per valore.

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

In Ruby, questo stesso sybmol è chiamato “hashrocket” e ho sentito che i programmatori C # usano anche 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 di lamdba

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

=> è solo una scorciatoia, quindi non è necessario utilizzare la parola chiave delegato e includere le informazioni sul tipo poiché possono essere desunte dal compilatore.