¿Cómo se pronuncia "=>" como se usa en las expresiones lambda en .Net

¡Muy raramente encuentro a otros programadores!

Mi pensamiento cuando vi el token por primera vez fue "implica que" ya que eso es lo que lo leería como en una prueba matemática, pero eso claramente no tiene sentido.

Entonces, ¿cómo digo o leo "=>" como en: -

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

¿O hay incluso una forma acordada de decirlo?

Usualmente digo 'tal que' cuando leo a ese operador.

En su ejemplo, p => p.Age> 16 se lee como "P, de modo que p.Age es mayor que 16."

De hecho, hice esta misma pregunta en los foros oficiales de prelanzamiento de linq, y Anders Hejlsberg respondió diciendo

Normalmente leo el operador => como "se convierte" o "para qué". Por ejemplo,
Func f = x => x * 2;
Func test = c => c.City == "Londres";
se lee como "x se convierte en x * 2" y "c para las cuales c.City es igual a Londres"

En cuanto a 'va', eso nunca tiene sentido para mí. 'p' no va a ninguna parte.

En el caso de leer el código a alguien, por ejemplo, por teléfono, entonces, siempre que sea un compañero programador de C #, solo usaría la palabra 'lambda', es decir, "p lambda p dot age mayor que dieciséis."

En los comentarios, Steve Jessop mencionó 'mapas para' en el caso de transformaciones, por lo que tomamos el ejemplo de Anders:

x => x * 2;

leería

x asigna a x veces 2.

Eso parece mucho más cercano a la intención real del código que 'se convierte' en este caso.

De MSDN :

Todas las expresiones lambda usan el operador lambda =>, que se lee como "va a".

Leer el 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. Nombre: "ver cliente se convierte en ver nombre de punto"

Para un predicado, (Cliente c) => c. Edad> 21: "el cliente ve de modo que la edad del punto es mayor que veintiuno"

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

"p wang edad de p mayor que 16"

He visto a gente decir "Flecha".

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

¿Qué tal "mapas para"? Es a la vez sucinto y podría decirse que es técnicamente más preciso (es decir, no sugiere un cambio de estado como con "va a" o "se convierte", no se confunde un conjunto con su función característica como con "tal que" o "para qué") que el Otras alternativas. Aunque si ya hay un estándar como parece implicar la página de MSDN, tal vez deberías seguir con eso (al menos para el código C #).

"Maps to" es mi pronunciación preferida. Hablando matemáticamente, una función "mapea" sus argumentos a su valor de retorno (incluso se podría llamar a la función "mapeo"), por lo que tiene sentido para mí usar esta terminología en la programación, particularmente como 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 se menciona sin contexto.

No lo he pensado mucho, pero solo digo sucintamente "a". Es breve y conciso, e implica que se pasa la variable a la expresión. Supongo que podría confundirse con el número 2 ("dos"), pero tiendo a pronunciar "a" más como "ta" cuando hablo. Nadie (que al menos conoce las lambdas) me ha dicho 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-of' e". Aunque me aferro a la "'lambda' c 'función' 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 deseo que hubieran hecho casi cualquier otra cosa por esto.

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

El problema es el uso de 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 infijo.

¡Esto puede ser un problema demasiado limitado!

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

Algo molesta sobre "va a" aunque puede ser lo más cercano que podamos llegar. "Ir a" implica una 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 es siempre un identificador simple en los casos utilizados hasta ahora [pero espere las extensiones que puedan confundir esto más adelante], creo que para "c => expresión", leería "c" función lambda-expresión "'o incluso" c' arg '' función 'expresión ". 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 así como "expresión 'arg' b 'arg' c 'función'.

Descubrir cómo traducir todo esto a otros idiomas es un ejercicio para el estudiante [; <).

Todavía me preocupo por "(b, c) => expresión" y otras variantes que pueden surgir si aún no lo han hecho. Quizás "'args' b, c 'función' expresión".

Después de toda esta reflexión, noto que voy a traducir "c => e" como "'lambda' c 'function' e" y me doy cuenta de que el mapeo a la forma exacta debe entenderse por contexto: λc (e ), c => e, f donde f (c) = e, etc.

Espero que la explicación de "ir a" prevalecerá simplemente porque aquí es donde una mayoría dominante verá las expresiones lambda por primera vez. Eso es una lástima. Un buen compromiso podría ser "c ' lambda-of ' e"

Si imagina una expresión lambda como el método anónimo que es, "va a" tiene bastante sentido.

(n => n == String.Empty)

n "va a" la expresión n == String.Empty.

Va al método anónimo, por lo que no tiene que ir al método en el código.

Lo siento por eso.

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

Además de adquirir el alcance anterior (todas las variables y constantes que están dentro del alcance de una línea de código normal 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 ("=>") contribuye con la estructura y el contenido del marco de pila utilizado para realizar la llamada a esta función. Se podría decir que la lista de valores contribuye tanto con las declaraciones de parámetros como con los argumentos que se pasan; en un código más convencional, estos determinan la estructura y el contenido del marco de pila utilizado para realizar la llamada a una función.

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

En la aplicación estrechamente 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 a favor de la intención del código, y esto lleva a " para lo cual "es tan sucinto y dice 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, debe usarse la forma más general "va a".

¿Pero por qué "va a"?

Porque "llena el marco de la pila del siguiente código" es demasiado largo para seguir diciéndolo. Supongo que se podría decir "es / se pasa a".

Una diferencia crucial entre los parámetros pasados ​​explícitamente y las variables capturadas (si no recuerdo mal, 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 bonita o tan integrada como la de Ruby |.

En Ruby, este mismo sybmol se llama "hashrocket", y he escuchado que los programadores de C # también usan ese término (aunque hacerlo es incorrecto).

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 de lamdba

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

=> es solo un atajo para que no tenga que usar la palabra clave delegado e incluir la información de tipo, ya que el compilador puede inferirla.

Mi término para => como se aplica a los resultados mostrados ejemplos

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

s donde s. Edad es mayor que 12 y s. Edad menor que 20

'result = x => x * 2'

x donde x se multiplica por 2

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

c donde c.city es equivalente a "Londres"

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

n donde n es una cadena vacía