Cómo pronuncio "= > " como se usa en expresiones lambda in.Net

De MSDN :

Todas las expresiones lambda usan la lambda operator=>, que se lee como " goes a".

Lectura de Código Por Teléfono

De Eric Lippert:

Yo personalmente diría c=>c+1 como "ver va a ver más uno". Algunas variaciones que he escuchado:

Para una proyección, (Cliente c) = >c.Name:"cliente ver se convierte en ver nombre de punto"

Para un predicado, (Customer c) = > c. Age > 21:"customer see such that see dot age is greater than twenty-one"

Siempre lo he llamado el "operador wang": -)

"p wang edad de p mayor de 16"

He visto a la gente decir, " Flecha."

Uso "va a" porque un libro de LINQ me dijo que:)

¿Qué tal "mapas a"? Es a la vez sucinto y posiblemente más técnicamente preciso (es decir, ninguna sugerencia de un cambio de estado como con "va a" o "se convierte", ninguna combinación de un conjunto con su función característica como con "tal que" o "para el cual") que las otras alternativas. Aunque si ya hay un estándar como la página de MSDN parece implicar, tal vez debería ir con eso (al menos para el código C#).

"Maps to" es mi pronunciación preferida. Matemáticamente hablando, una función "mapea" sus argumentos a su valor de retorno (uno podría incluso llamar a la función un "mapeo"), por lo que tiene sentido para mí usar esta terminología en la programación, particularmente ya que la programación funcional (especialmente el cálculo lambda) está muy cerca de las matemáticas. También es más neutral que "se convierte"," va a", etc., ya que no sugiere un cambio de estado, como mencionó contextfree.

No lo he pensado mucho, pero solo digo sucintamente "a". Es corto y conciso, e implica que la variable se pasa a la expresión. Supongo que podría confundirse con el número 2 ("dos"), pero tiendo a pronunciar "to" más como "ta" cuando hablo. Nadie (quien conoce lambdas, al menos) me ha dicho nunca que lo consideraban 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"

Mi respuesta corta: "c 'lambda-de' e". Aunque me aferro a la función" lambda " c "e", creo que lambda-of es el compromiso ecuménico. El análisis sigue.

Esta es una gran pregunta aunque solo sea por las respuestas extrañas. La mayoría de las traducciones tienen otros significados que las expresiones lambda, lo que lleva a interpretaciones exóticas. Como un viejo hacker de expresión lambda, simplemente ignoro la notación. NET y la reescribo como lambda en mi cabeza mientras desearía que hubieran hecho casi cualquier otra cosa por esto.

Para narrar código por teléfono, quieres que alguien pueda escribir el código en secuencia. Eso es un problema, por supuesto, pero lambda-arrow o algo así es probablemente lo mejor que puedes conseguir, o tal vez lambda-in, pero lambda-of es el más preciso.

El problema es el uso del infijo y cómo nombrar todo y el papel de las partes izquierda y derecha con algo que funciona cuando se habla en el lugar del infijo.

Esto puede ser un exceso de restricciones problema!

No usaría "tal que" porque eso implica que el lado derecho es un predicado que el lado izquierdo debe satisfacer. Eso es muy diferente de hablar de un lado derecho del que se ha abstraído el lado izquierdo como parámetro funcional. (La declaración de MSDN sobre "Todas las expresiones lambda" es simplemente ofensiva e inexacta.)

Algo se enfada acerca de "va a" aunque puede ser lo más cerca que podamos llegar. "Va a" implica un transformación, pero no hay exactamente alguna variable c que vaya a una expresión en c. La abstracción de una función es un poco esquiva. Podría acostumbrarme a esto, pero todavía anhelo algo que enfatice la abstracción de la variable.

Dado que el lado izquierdo siempre es un identificador simple en los casos utilizados hasta ahora [pero espere extensiones que puedan confundir esto más adelante], creo que para" c = > expression "leería " c' lambda-function 'expression "'o incluso" c 'arg' expresión' function'". En el último caso, podría decir cosas como "b' arg 'c' arg '' function 'expression".

Podría ser mejor dejar aún más claro que se está introduciendo una expresión lambda y decir algo como "'arg' b 'arg' c 'function' expression".

Averiguar cómo traducir todo esto a otros idiomas es un ejercicio para el estudiante [;

Todavía me preocupan "(b, c) => expression " y otras variantes que pueden surgir si no lo he hecho ya. Quizás "' args 'b, c' function 'expression".

Después de toda esta reflexión, noto que estoy llegando a traducir "c => e" como "'lambda' c 'function' e" y notando que la asignación a la forma exacta debe entenderse por contexto: λc(e), c => e, f donde f(c) = e, etc.

Espero que la explicación "goes-to" prevalezca simplemente porque aquí es donde una mayoría dominante va a ver expresiones lambda por primera vez. Eso es un piedad. Un buen compromiso podría ser " c ' lambda-of ' e "

Si imaginas una expresión lambda como el método anónimo que es, "goes to" tiene bastante sentido.

(n => n == String.Empty)

N "va a" la expresión n = = Cadena.Vaciar.

Va al método anónimo, así que no tienes que ir al método en el código!

Lo siento por eso.

Honestamente, no me gusta usar "goes to" en mi cabeza, pero vi a otras personas diciendo que parecía extraño, y pensé en aclararlo.

Aparte de adquirir el ámbito anterior (todas las variables y constantes que están en el ámbito de una línea normal de código en el punto donde se produce una expresión lambda están disponibles para el código de la expresión), una expresión lambda es esencialmente azúcar sintáctica para una función en línea.

La lista de valores a la izquierda del operador de producción ("=>") aporta la estructura y el contenido del marco de pila utilizado para hacer la llamada a esta función. Se podría decir que la lista de valores contribuye tanto las declaraciones de parámetros como los argumentos que se pasan; en código más convencional estos determinan la estructura y el contenido del marco de pila utilizado para hacer la llamada a una función.

Como resultado, los valores "van a" el código de expresión. Preferiría decir "define el marco de pila para" o "va" ? :)

En la aplicación estrictamente definida de expresiones booleanas utilizadas como condiciones de filtro (un uso dominante de expresiones lambda ampliamente considerado por otras respuestas a esta pregunta) es muy razonable omitir el método en favor de la intención del código, y esto conduce a "para el cual" ser tan sucinto y decir más sobre el significado del código.

Sin embargo, las expresiones lambda no son la única provincia de Linq y fuera de este contexto se debe usar la forma más general "goes to".

Pero ¿por qué "va a" ?

Porque "rellena el marco de pila del siguiente código" es demasiado largo para mantenerlo diciéndolo. Supongo que podrías decir "es / son pasados a".

Una diferencia crucial entre los parámetros pasados explícitamente y las variables capturadas (si recuerdo correctamente, corrígeme si me equivoco) es que los primeros se pasan por referencia y los segundos por valor.

Parte del problema es que puedes leerlo en voz alta de manera diferente dependiendo de cómo esté estructurado. Es una pena que no sea tan bonito o tan integrado como el |'s de Ruby.

En Ruby, este mismo sybmol se llama "hashrocket", y he oído que los programadores de C# también usan ese término (aunque hacerlo está mal).

Mis dos centavos:

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

" La expresión Lambda con el parámetro s es { return s.Age > 12 && s.Age < 20; }"

Me gusta esto porque me recuerda de dónde viene la expresión lamdba

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

=> es solo un atajo por lo que no tiene que usar la palabra clave delegate e incluir la información de tipo ya que puede ser inferida por el compilador.