Как произносится «=>», как используется в лямбда-выражениях в .Net?

Я очень редко встречаю других программистов!

Моя мысль, когда я впервые увидел токен, была «подразумевает, что», потому что это то, что он будет читать как математическое доказательство, но это явно не его смысл.

Так как же сказать или прочитать "=>", как в: -

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

Или есть даже согласованный способ сказать это?

Я обычно говорю «такой, что» при чтении этого оператора.

В вашем примере p => p.Age> 16 читается как «P, так что p.Age больше 16.»

На самом деле, я задал этот вопрос на официальных предварительных форумах linq, и Андерс Хейлсберг ответил, что

Я обычно читаю оператор => как «становится» или «для чего». Например,
Func f = x => x * 2;
Func test = c => c.City == "Лондон";
читается как «x становится x * 2» и «c, для которого c.City равен Лондону»

Что касается «идет» - это никогда не имело смысла для меня. «р» никуда не денется.

В случае чтения кода кому-то, скажем, по телефону, тогда, пока он является программистом на C #, я бы просто использовал слово «лямбда», то есть «p lambda p dot age-than шестнадцать."

В комментариях Стив Джессоп упомянул «преобразования в» в случае преобразований - так, например, на примере Андерса:

x => x * 2;

будет читать

х отображается в х раз 2.

Это кажется гораздо ближе к реальному замыслу кода, чем «становится» для этого случая.

Из MSDN :

Все лямбда-выражения используют лямбда-оператор =>, который читается как «идет».

Чтение кода по телефону

От Эрика Липперта:

Я лично сказал бы, что c => c + 1 как "видеть, чтобы видеть плюс один". Некоторые варианты, которые я слышал:

Для проекции (Customer c) => c.Name: "клиент видит, видит имя точки"

Для предиката (Customer c) => c.Age> 21: «клиент видит так, что точка видит возраст больше двадцати одного»

Я всегда называл это "оператор Ван" :-)

"р ван возраст р больше 16"

Я видел, как люди говорят: «Стрелка».

Я использую "идет", потому что книга LINQ сказала мне :)

Как насчет "карты для"? Это одновременно лаконично и, возможно, более технически точно (т.е. нет предположения об изменении состояния, как в случае «идет» или «становится»), нет сопоставления множества с его характеристической функцией, как с «таким, что» или «для которого»), чем другие альтернативы. Хотя, если на странице MSDN уже есть стандарт, возможно, вам следует просто пойти по этому пути (по крайней мере, для кода C #).

«Карты в» - мое предпочтительное произношение. Математически говоря, функция «отображает» свои аргументы на свое возвращаемое значение (можно даже назвать функцию «отображением»), поэтому мне имеет смысл использовать эту терминологию в программировании, особенно в качестве функционального программирования (особенно лямбда-исчисления) очень близко к математике. Он также более нейтрален, чем «становится», «уходит» и т. Д., Поскольку не предполагает смены состояния, как уже упоминалось в контексте.

Я не думал об этом много, но я просто лаконично говорю «к». Это коротко и сжато, и означает , что переменная передается в выражении. Я полагаю, что это может быть перепутано с цифрой 2 («два»), но я склонен произносить «на» больше как «та» при разговоре. Никто (кто знает лямбды, по крайней мере) никогда не говорил мне, что они думают, что это неоднозначно ...

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

Мой короткий ответ: "c 'лямбда-о' e". Хотя я цепляюсь за «лямбда-с» функцию «е», я думаю, что лямбда-о - это экуменический компромисс. Анализ следует.

Это отличный вопрос хотя бы для причудливых ответов. Большинство переводов имеют иные значения, чем для лямбда-выражений, что приводит к экзотическим интерпретациям. Как старый хакер с лямбда-выражениями, я просто игнорирую нотацию .NET и переписываю ее как лямбда-выражения в своей голове, желая, чтобы они сделали для этого почти все остальное.

Для передачи кода по телефону вы хотите, чтобы кто-то мог записать код по порядку. Это, конечно, проблема, но лямбда-стрелка или что-то, вероятно, лучшее, что вы можете получить, или, может быть, лямбда-в, но лямбда-в является наиболее точным.

Проблема заключается в использовании инфикса и в том, как назвать всю вещь и роль левой и правой частей чем-то, что работает, когда говорят в месте инфикса.

Это может быть чрезмерно ограниченной проблемой!

Я бы не использовал «такой, что», потому что это означает, что правая часть является предикатом, который должна удовлетворять левая часть. Это очень отличается от разговора о правой стороне, от которой левая сторона была выделена в качестве функционального параметра. (Заявление MSDN о «всех лямбда-выражениях» просто оскорбительно и неточно.)

Что-то раздражает в «идет», хотя это может быть как можно ближе. «Идет к» подразумевает преобразование, но нет точно некоторой переменной с, которая идет к выражению в с. Абстракция к функции немного неуловима. Я мог бы привыкнуть к этому, но я все еще жажду чего-то, что подчеркивает абстракцию переменной.

Так как левая часть всегда является простым идентификатором в используемых до сих пор случаях [но дождитесь расширений, которые могут запутать это позже], я думаю, что для «c => expression» я бы прочитал «c» выражение lambda-function ' "'или даже" c' arg '' function 'expression ". В последнем случае я мог бы сказать такие вещи, как "b 'arg' c 'arg' 'function' expression".

Возможно, было бы лучше прояснить, что вводится лямбда-выражение, и сказать что-то вроде «arg» b «arg» c «function» expression ».

Выяснить, как перевести все это на другие языки, - это упражнение для студента [; <).

Я все еще беспокоюсь о "(b, c) => expression" и других вариантах, которые могут возникнуть, если они этого еще не сделали. Возможно "args" b, c "function" expression ".

После всего этого размышления я замечаю, что перехожу к переводу «c => e» как «lambda» c «function 'e» и замечаю, что отображение на точную форму следует понимать по контексту: λc (e ), c => e, f, где f (c) = e и т. д.

Я ожидаю, что объяснение «уходит» будет преобладать просто потому, что именно здесь доминирующее большинство впервые увидит лямбда-выражения. Какая жалость. Хорошим компромиссом может быть "c ' lambda-of ' e"

Если вы представляете лямбда-выражение как анонимный метод, то оно «подходит для» имеет достаточно приличный смысл.

(n => n == String.Empty)

n "идет" к выражению n == String.Empty.

Это относится к анонимному методу, поэтому вам не нужно идти к методу в коде!

Простите за это.

Честно говоря, я не люблю использовать «идет к» в моей голове, но я видел, как другие люди говорили, что это кажется странным, и я подумал, что проясню это.

Помимо получения предыдущей области видимости (все переменные и константы, которые находятся в области видимости для нормальной строки кода в точке, где происходит лямбда-выражение, доступны для кода выражения), лямбда-выражение по сути является синтаксическим сахаром для встроенной функции.

Список значений слева от производственного оператора ("=>") вносит вклад в структуру и содержимое стекового фрейма, используемого для вызова этой функции. Можно сказать, что в список значений входят как объявления параметров, так и передаваемые аргументы; в более традиционном коде они определяют структуру и содержимое кадра стека, используемого для вызова функции.

В результате значения «идут» в коде выражения. Вы бы предпочли сказать «определяет фрейм стека» или «уходит»? :)

В узко определенном применении булевых выражений, используемых в качестве условий фильтрации (доминирующее использование лямбда-выражений, широко рассмотренное другими ответами на этот вопрос), очень разумно пропустить метод в пользу намерения кода, и это приводит к " за что «быть таким же кратким и говорить больше о значении кода.

Однако лямбда-выражения не являются единственной провинцией Линка, и вне этого контекста следует использовать более общую форму «идет».

Но почему "уходит"?

Потому что «заполняет кадр стека следующего кода» слишком долго, чтобы продолжать это говорить. Я полагаю, вы могли бы сказать, "это / передано".

Принципиальное различие между явно переданными параметрами и захваченными переменными (если я правильно помню - поправьте меня, если я ошибаюсь) заключается в том, что первые передаются по ссылке, а вторые - по значению.

Частично проблема заключается в том, что вы можете прочитать его вслух по-разному в зависимости от его структуры. Жаль, что это не так красиво и не так интегрировано, как у Рубина.

В Ruby этот же самый sybmol называется hashrocket, и я слышал, что программисты на C # тоже используют этот термин (хотя это неправильно).

Мои два цента:

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

«Лямбда-выражение с параметром s равно { return s.Age > 12 && s.Age < 20;}»

Мне нравится это, потому что это напоминает мне о том, откуда исходит выражение lamdba

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

=> это просто ярлык, поэтому вам не нужно использовать ключевое слово делегат и включать информацию о типе, так как он может быть выведен компилятором.

Мой термин для => применительно к приведенным в примере результатам

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

s, где s.Age больше 12 и s.Age меньше 20

'result = x => x * 2'

х, где х умножается на 2

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

c где c.city эквивалентно "Лондону"

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

n где n - пустая строка