Como se pronuncia "=>" conforme usado nas expressões lambda no .Net

Eu raramente encontro outros programadores!

Meu pensamento, quando vi pela primeira vez, o token era "implica que", já que é isso que ele leria como uma prova matemática, mas que claramente não é o seu sentido.

Então, como digo ou leio "=>" como em: -

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

Ou existe mesmo uma maneira acordada de dizer isso?

Eu costumo dizer 'tal que' ao ler esse operador.

No seu exemplo, p => p.Age> 16 é lido como "P, de modo que p.Age seja maior que 16."

De fato, fiz essa pergunta nos fóruns oficiais de pré-lançamento do linq, e Anders Hejlsberg respondeu dizendo:

Normalmente leio o operador => como "se torna" ou "para o qual". Por exemplo,
Func f = x => x * 2;
Teste Func = c => c.City == "London";
lê como "x se torna x * 2" e "c para o qual c.City é igual a Londres"

Tanto quanto 'vai para' - isso nunca fez sentido para mim. 'p' não vai a lugar nenhum.

No caso de ler código para alguém, digamos, por telefone, desde que seja um colega programador de C #, eu usaria a palavra 'lambda' - ou seja, "p lambda p dot age maior que dezesseis."

Nos comentários, Steve Jessop mencionou 'maps to' no caso de transformações - tomando o exemplo de Anders:

x => x * 2;

Iria ler

x mapeia x vezes 2.

Isso parece muito mais próximo da intenção real do código do que 'se torna' para este caso.

Do MSDN :

Todas as expressões lambda usam o operador lambda =>, que é lido como "vai para".

Lendo código pelo telefone

De Eric Lippert:

Pessoalmente, eu diria que c => c + 1 como "veja vai ver mais um". Algumas variações que eu já ouvi:

Para uma projeção, (Cliente c) => c.Name: "o cliente vê se torna ver o nome do ponto"

Para um predicado, (Cliente c) => c.Idade> 21: "o cliente vê que a idade do ponto é maior que vinte e um"

Eu sempre o chamei de "operador wang" :-)

"p wang idade de p maior que 16"

Eu já vi pessoas dizerem "Arrow".

Eu uso "vai para" porque um livro do LINQ me disse para :)

Que tal "mapeia para"? É ao mesmo tempo sucinto e sem dúvida mais preciso tecnicamente (ou seja, nenhuma sugestão de mudança de estado como "vai para" ou "torna-se", nenhuma combinação de um conjunto com sua função característica como com "tal que" ou "para qual") do que o outras alternativas. Embora se já exista um padrão como a página do MSDN pareça sugerir, talvez você deva apenas segui-lo (pelo menos no código C #).

"Mapeia para" é minha pronúncia preferida. Matematicamente falando, uma função "mapeia" seus argumentos para seu valor de retorno (pode-se até chamar a função de "mapeamento"); portanto, faz sentido usar essa terminologia em programação, particularmente como programação funcional (especialmente o cálculo lambda) está muito perto da matemática. Também é mais neutro do que "torna-se", "vai para" etc., pois não sugere mudança de estado, como mencionado no contexto.

Eu não pensei muito sobre isso, mas digo sucintamente "para". É curto e conciso, e implica que a variável é passada para a expressão. Suponho que possa ser confundido com o número 2 ("dois"), mas costumo pronunciar "para" mais como "ta" ao falar. Ninguém (que conhece lambdas, pelo menos) jamais me disse que achava ambíguo ...

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

Minha resposta curta: "c 'lambda-of' e". Embora eu me apegue à "função lambda 'c' 'e", acho que lambda-of é o compromisso ecumênico. A análise segue.

Essa é uma ótima pergunta, apenas pelas respostas bizarras. A maioria das traduções tem outros significados que não as expressões lambda, levando a interpretações exóticas. Como um antigo hacker de expressão lambda, simplesmente ignoro a notação .NET e a reescrevo como lambda na minha cabeça, desejando que eles tivessem feito quase qualquer outra coisa para isso.

Para narrar o código pelo telefone, você deseja que alguém seja capaz de escrever o código em sequência. Isso é um problema, é claro, mas a seta lambda ou algo é provavelmente o melhor que você pode obter, ou talvez a entrada lambda, mas a lambda-of é a mais precisa.

O problema é o uso do infixo e como nomear a coisa toda e o papel das partes esquerda e direita com algo que funciona quando falado no local do infixo.

Este pode ser um problema excessivamente restrito!

Eu não usaria "tal que" porque isso implica que o lado direito é um predicado que o lado esquerdo deve satisfazer. Isso é muito diferente de falar sobre o lado direito do qual o lado esquerdo foi abstraído como um parâmetro funcional. (A declaração do MSDN sobre "Todas as expressões lambda" é simplesmente ofensiva e imprecisa.)

Algo incomoda sobre "vai para", embora possa ser o mais próximo possível. "Vai para" implica uma transformação, mas não há exatamente alguma variável c que vá para uma expressão em c. A abstração de uma função é um pouco ilusória. Eu poderia me acostumar com isso, mas ainda anseio por algo que enfatize a abstração da variável.

Como o lado esquerdo é sempre um identificador simples nos casos usados ​​até o momento [mas espere por extensões que possam confundir isso mais tarde], penso em "c => expression" eu leria "c 'lambda-function' expression "'ou mesmo" c' arg '' função 'expressão ". No último caso, eu poderia dizer coisas como "b 'arg' c 'arg' 'function' expression".

Talvez seja melhor deixar ainda mais claro que uma expressão lambda está sendo introduzida e dizer algo como "expressão 'arg' b 'arg' c 'function'".

Descobrir como traduzir tudo isso para outros idiomas é um exercício para o aluno [; <).

Eu ainda me preocupo com "(b, c) => expressão" e outras variantes que podem surgir se ainda não o foram. Talvez "'args' b, c 'function' expression".

Depois de toda essa reflexão, percebo que estou traduzindo "c => e" como "'função lambda' c '' e" e percebendo que o mapeamento para a forma exata deve ser entendido pelo contexto: λc (e ), c => e, f em que f (c) = e, etc.

Espero que a explicação "vá para" prevaleça simplesmente porque é aqui que a maioria dominante verá expressões lambda pela primeira vez. É uma pena. Um bom compromisso pode ser "c ' lambda-of ' e"

Se você imaginar uma expressão lambda como o método anônimo, "vai para" faz bastante sentido.

(n => n == String.Empty)

n "vai para" a expressão n == String.Empty.

Ele vai para o método anônimo, para que você não precise ir para o método no código!

Desculpe por isso.

Honestamente, eu não gosto de usar "vai para" na minha cabeça, mas vi outras pessoas dizendo que pareciam estranhas e pensei em esclarecer isso.

Além de adquirir o escopo anterior (todas as variáveis ​​e constantes que estão no escopo de uma linha de código normal no ponto em que ocorre uma expressão lambda estão disponíveis para o código da expressão), uma expressão lambda é essencialmente um açúcar sintático para uma função em linha.

A lista de valores à esquerda do operador de produção ("=>") contribui com a estrutura e o conteúdo do quadro de pilha usado para fazer a chamada para esta função. Você poderia dizer que a lista de valores contribui com as declarações de parâmetro e os argumentos passados; em código mais convencional, eles determinam a estrutura e o conteúdo do quadro de pilha usado para fazer a chamada para uma função.

Como resultado, os valores "vão para" o código da expressão. Você prefere dizer "define o quadro da pilha para" ou "vai para"? :)

Na aplicação estritamente definida de expressões booleanas usadas como condições de filtro (um uso dominante de expressões lambda amplamente consideradas por outras respostas a essa pergunta), é muito razoável ignorar o método em favor da intenção do código, e isso leva a " para o qual "ser tão sucinto e dizer mais sobre o significado do código.

No entanto, as expressões lambda não são a única província do Linq e, fora desse contexto, a forma mais geral "vai para" deve ser usada.

Mas por que "vai para"?

Porque "preenche o quadro de pilha do código a seguir" é muito longo para continuar dizendo isso. Suponho que você poderia dizer "é / é passado para".

Uma diferença crucial entre parâmetros explicitamente passados ​​e variáveis ​​capturadas (se bem me lembro - me corrija se estiver errado) é que os primeiros são passados ​​por referência e os últimos por valor.

Parte do problema é que você pode lê-lo em voz alta de maneira diferente, dependendo de como está estruturado. É uma pena que não seja tão bonito ou tão integrado quanto o do ruby.

Em Ruby, esse mesmo sybmol é chamado "hashrocket" e ouvi programadores de C # usarem esse termo também (mesmo que isso esteja errado).

Meus dois centavos:

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

"Expressão Lambda com o parâmetro s é { return s.Age > 12 && s.Age < 20;}"

Eu gosto disso porque me lembra de onde vem a expressão lamdba

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

=> é apenas um atalho para que você não precise usar a palavra-chave delegada e incluir as informações de tipo, pois elas podem ser inferidas pelo compilador.

Meu termo para => conforme aplicado aos exemplos mostrados resulta

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

s onde s.A idade é maior que 12 e s.A idade é menor que 20

'result = x => x * 2'

x onde x é multiplicado por 2

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

c onde c.city é equivalente a "London"

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

n onde n é uma string vazia