expresiones - lambda c# tutorial

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

Question

¡Rara vez conozco a otros programadores!

Mi pensamiento cuando vi por primera vez el token fue "implica eso", ya que eso es lo que leería como una prueba matemática pero que claramente no es su 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?

Answer 1

"Maps to" es mi pronunciación preferida. Matemáticamente hablando, una función "asigna" sus argumentos a su valor de retorno (incluso podría llamar a la función un "mapeo"), por lo que tiene sentido para mí usar esta terminología en 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", "se dirige a", etc., ya que no sugiere un cambio de estado, como se mencionó sin contexto.

Answer 2

¿Qué tal "mapas para"? Es breve y podría decirse que es más precisa desde el punto de vista técnico (es decir, no sugiere un cambio de estado como "pasa" o "se convierte", no hay una combinación de su función característica como "tal" o "para el cual") que el otras alternativas Aunque si ya existe un estándar como parece implicar la página MSDN, tal vez debería ir con eso (al menos para el código C #).

Answer 3

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

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

En la aplicación estrechamente definida de expresiones booleanas usadas como condiciones de filtro (un uso dominante de expresiones lambda ampliamente consideradas 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 breve como 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, debe usarse la forma más general "goes to".

Pero, ¿por qué "va a"?

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

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

Answer 4

Desde MSDN :

Todas las expresiones lambda utilizan el operador lambda =>, que se lee como "goes to".

Answer 5

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

Answer 6

He visto a personas decir, "Arrow".

Answer 7

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

Esta es una gran pregunta si solo para 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 haber hecho casi todo lo demás para 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 es probablemente lo mejor que se puede obtener, o tal vez lambda-in, pero lambda-of es la más precisa.

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 infijo.

¡Esto puede ser un problema sobrecargado!

No usaría "tal cosa" 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 se ha abstraído el lado izquierdo como un parámetro funcional. (La declaración de MSDN sobre "Todas las expresiones lambda" es simplemente ofensiva e inexacta).

Algo irrita acerca de "va hacia" aunque puede ser lo más cerca 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.

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

Sería mejor aclarar aún más que se está introduciendo una expresión lambda y decir algo así como "''arg'' b ''arg'' c ''función'' expresión ''.

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

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, me doy cuenta de que estoy traduciendo "c => e" como "''lambda'' c ''función'' e" y advierto que el mapeo a la forma exacta debe ser entendido por el contexto: λc (e ), c => e, f donde f (c) = e, etc.

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

Answer 8

Mis dos centavos:

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

"Lambda Expression con parámetro s es { return s.Age > 12 && s.Age < 20; }"

Me gusta 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 acceso directo, por lo que no tiene que usar la palabra clave delegar e incluir la información del tipo, ya que el compilador puede inferirlo.

Answer 9

No lo he pensado mucho, pero simplemente digo "a". Es breve 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 "a" más como "ta" al hablar. Nadie (quién sabe lambdas, al menos) me ha dicho alguna vez que pensaban que era 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"

Answer 10

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''s.

Answer 11

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 == String.Empty.

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 "va a" en mi cabeza, pero vi a otras personas diciendo que parecía raro, y pensé en aclararlo.

Answer 12

Siempre lo llamé el "operador wang" :-)

"p wang edad de p mayor que 16"

Answer 13

Suelo decir ''tal que'' al leer ese operador.

En su ejemplo, p => p.Age> 16 se lee como "P", de modo que p.Age sea 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 el cual". Por ejemplo,
Func f = x => x * 2;
Prueba de Func = c => c.City == "London";
se lee como "x se convierte en x * 2" y "c para lo cual c. La ciudad es igual a Londres"

En lo que respecta a "ir a", eso nunca tuvo sentido para mí. ''p'' no va a ninguna parte.

En el caso de leer el código a alguien, por ejemplo, por teléfono, mientras sean programadores de C #, simplemente usaría la palabra ''lambda'', es decir, "p lambda p dot age greater-than dieciséis."

En los comentarios Steve Jessop mencionó ''mapas para'' en el caso de las transformaciones, tomando el ejemplo de Anders:

x => x * 2;

leería

x mapas a x veces 2.

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

Answer 14

Uso "goes to" porque un libro LINQ me lo dijo :)

Answer 15

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

Para un predicado, (Cliente c) => c.Edad> 21: "cliente vea tal que vea la edad del punto sea mayor que veintiuno"