Comment prononcer "=>" tel qu'il est utilisé dans les expressions lambda dans .Net
Je rencontre très rarement d'autres programmeurs!
Ma pensée quand j'ai vu le jeton pour la première fois était "implique que" puisque c'est ce qu'il interpréterait comme dans une preuve mathématique mais ce n'est clairement pas son sens.
Alors, comment puis-je dire ou lire "=>" comme dans: -
IEnumerable<Person> Adults = people.Where(p => p.Age > 16)
Ou existe-t-il même une façon convenue de le dire?
Je dis habituellement "tel que" lors de la lecture de cet opérateur.
Dans votre exemple, p => p.Age> 16 se lit comme "P, de sorte que p.Age est supérieur à 16."
En fait, j'ai posé cette question sur les forums officiels de pré-version de linq, et Anders Hejlsberg a répondu en disant
Je lis généralement l'opérateur => comme "devient" ou "pour lequel". Par exemple,
Func f = x => x * 2;
Test Func = c => c.City == "Londres";
se lit comme "x devient x * 2" et "c pour lequel c.City est égal à Londres"
En ce qui concerne "va à" - cela n'a jamais eu de sens pour moi. 'p' ne va nulle part.
Dans le cas de la lecture de code à quelqu'un, par exemple, par téléphone, alors tant qu'il est un collègue programmeur C #, j'utiliserais simplement le mot "lambda" - c'est-à-dire, "p lambda p age age supérieur à seize."
Dans les commentaires, Steve Jessop a mentionné des "cartes à" dans le cas des transformations - prenant ainsi l'exemple d'Anders:
x => x * 2;
lirait
x correspond à x fois 2.
Cela semble beaucoup plus proche de l'intention réelle du code que "devient" dans ce cas.
De MSDN :
Toutes les expressions lambda utilisent l'opérateur lambda =>, qui se lit comme "va à".
De Eric Lippert:
Personnellement, je dirais c => c + 1 comme "voir va voir plus un". Quelques variations que j'ai entendues:
Pour une projection, (Client c) => c.Nom: "client voir devient voir nom du point"
Pour un prédicat, (Client c) => c.Age> 21: "client voir tel que voir l'âge du point est supérieur à vingt et un"
Je l'ai toujours appelé "l'opérateur wang" :-)
"p wang âge de p supérieur à 16"
J'ai vu des gens dire "Flèche".
J'utilise "va à" car un livre LINQ me l'a dit :)
Que diriez-vous des "cartes vers"? Il est à la fois succinct et sans doute plus précis sur le plan technique (c'est-à-dire aucune suggestion de changement d'état comme avec "va à" ou "devient", pas de confusion d'un ensemble avec sa fonction caractéristique comme avec "tel que" ou "pour lequel") que le d'autres alternatives. Bien que s'il existe déjà une norme comme la page MSDN semble l'impliquer, vous devriez peut-être simplement y aller (au moins pour le code C #).
"Maps to" est ma prononciation préférée. Mathématiquement parlant, une fonction "mappe" ses arguments à sa valeur de retour (on pourrait même appeler la fonction un "mappage"), il est donc logique pour moi d'utiliser cette terminologie dans la programmation, en particulier comme programmation fonctionnelle (en particulier le calcul lambda) est très proche des mathématiques. Il est également plus neutre que "devient", "va à", etc., car il ne suggère pas de changement d'état, comme mentionné sans contexte.
Si vous imaginez une expression lambda comme la méthode anonyme qu'elle est, "va à" est suffisamment sensé.
(n => n == String.Empty)
n "va à" l'expression n == String.Empty.
Il va à la méthode anonyme, vous n'avez donc pas à aller à la méthode dans le code!
Désolé.
Honnêtement, je n'aime pas utiliser "va à" dans ma tête, mais j'ai vu d'autres personnes dire que cela semblait bizarre, et j'ai pensé que je clarifierais cela.
Je n'y ai pas beaucoup réfléchi, mais je dis simplement "à". C'est court et concis, et implique que la variable est passée à l'expression. Je suppose que cela pourrait être confondu avec le chiffre 2 ("deux"), mais j'ai tendance à prononcer "à" plus comme "ta" en parlant. Personne (qui connaît au moins les lambdas) ne m'a jamais dit qu'ils pensaient que c'était ambigu ...
// "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"
Ma réponse courte: "c 'lambda-of' e". Bien que je m'accroche à la "fonction lambda" c "", je pense que lambda-of est le compromis œcuménique. L'analyse suit.
C'est une excellente question, ne serait-ce que pour les réponses bizarres. La plupart des traductions ont d'autres significations que pour les expressions lambda, conduisant à des interprétations exotiques. En tant que vieux hacker d'expression lambda, j'ignore simplement la notation .NET et la réécris comme lambda dans ma tête tout en souhaitant qu'ils aient fait presque n'importe quoi d'autre pour cela.
Pour raconter du code par téléphone, vous voulez que quelqu'un puisse écrire le code dans l'ordre. C'est un problème, bien sûr, mais lambda-arrow ou quelque chose est probablement le meilleur que vous puissiez obtenir, ou peut-être lambda-in, mais lambda-of est le plus précis.
Le problème est l'utilisation de l'infixe et comment nommer le tout et le rôle des parties gauche et droite avec quelque chose qui fonctionne quand il est parlé à la place de l'infixe.
Cela peut être un problème trop contraint!
Je n'utiliserais pas "tel que" car cela implique que le côté droit est un prédicat que le côté gauche devrait satisfaire. C'est très différent de parler d'un côté droit dont le côté gauche a été extrait comme paramètre fonctionnel. (L'instruction MSDN sur "Toutes les expressions lambda" est tout simplement offensante et inexacte.)
Quelque chose cloche à propos de "va à" bien qu'il puisse être aussi proche que possible. "Va à" implique une transformation, mais il n'y a pas exactement une variable c qui va à une expression en c. L'abstraction d'une fonction est un peu insaisissable. Je pourrais m'habituer à cela, mais j'aspire toujours à quelque chose qui met l'accent sur l'abstraction de la variable.
Étant donné que le côté gauche est toujours un identifiant simple dans les cas utilisés jusqu'à présent [mais attendez les extensions qui peuvent le confondre plus tard], je pense que pour "c => expression", je lirais "c 'expression lambda-function' "'ou même" c' arg '' fonction 'expression ". Dans le dernier cas, je pourrais alors dire des choses comme "b 'arg' c 'arg' 'fonction' expression".
Il serait peut-être préférable de rendre encore plus clair qu'une expression lambda est introduite et de dire quelque chose comme "'arg' b 'arg' c 'function' expression".
Trouver comment traduire tout cela dans d'autres langues est un exercice pour l'élève [; <).
Je m'inquiète toujours de "(b, c) => expression" et d'autres variantes qui pourraient voir le jour si ce n'est déjà fait. Peut-être "expression 'args' b, c 'fonction'".
Après toutes ces rêveries, je remarque que je viens de traduire "c => e" par "'lambda' c 'fonction' e" et de remarquer que la mise en correspondance avec la forme exacte doit être comprise par le contexte: λc (e ), c => e, f où f(c) = e, etc.
Je m'attends à ce que l'explication "va à" l'emporte simplement parce que c'est là qu'une majorité dominante va voir des expressions lambda pour la première fois. C'est dommage. Un bon compromis pourrait être "c 'lambda-of' e"
Outre l'acquisition de la portée précédente (toutes les variables et constantes qui sont à la portée d'une ligne de code normale au point où une expression lambda se produit sont disponibles pour le code de l'expression), une expression lambda est essentiellement du sucre syntaxique pour une fonction en ligne.
La liste de valeurs à gauche de l'opérateur de production ("=>") contribue à la structure et au contenu du cadre de pile utilisé pour effectuer l'appel à cette fonction. Vous pourriez dire que la liste de valeurs contribue à la fois aux déclarations de paramètres et aux arguments passés; dans un code plus conventionnel, ceux-ci déterminent la structure et le contenu de la trame de pile utilisée pour effectuer l'appel à une fonction.
Par conséquent, les valeurs "vont à" le code d'expression. Préférez-vous plutôt "définit le cadre de pile pour" ou "va à"? :)
Dans l'application étroitement définie d'expressions booléennes utilisées comme conditions de filtrage (une utilisation dominante d'expressions lambda largement envisagée par d'autres réponses à cette question), il est très raisonnable d'ignorer la méthode en faveur de l'intention du code, ce qui conduit à " pour lequel "être tout aussi succinct et en dire plus sur la signification du code.
Cependant, les expressions lambda ne sont pas la seule province de Linq et en dehors de ce contexte, la forme plus générale "va à" devrait être utilisée.
Mais pourquoi "va à"?
Parce que "remplit le cadre de pile du code suivant" est beaucoup trop long pour continuer à le dire. Je suppose que vous pourriez dire "est/est passé à".
Une différence cruciale entre les paramètres explicitement transmis et les variables capturées (si je me souviens bien - corrigez-moi si je me trompe) est que les premiers sont transmis par référence et les seconds par valeur.
Une partie du problème est que vous pouvez le lire à haute voix différemment selon sa structure. C'est dommage que ce ne soit pas aussi joli ou aussi intégré que celui de Ruby |.
Dans Ruby, ce même symbole est appelé "hashrocket", et j'ai entendu des programmeurs C # utiliser ce terme aussi (même si cela est mal).