.Net에서 람다 식에 사용 된“=>”을 발음하는 방법

나는 다른 프로그래머를 거의 만나지 않습니다!

내가 처음 토큰을 보았을 때의 내 생각은 "그것을 암시한다"는 것입니다. 왜냐하면 그것이 수학적 증거로 읽었을 것이기 때문입니다. 그러나 그것은 그 의미가 아닙니다.

그래서 어떻게 "=>"를 말하거나 읽습니까?

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

아니면 동의하는 방법이 있습니까?

나는 보통 그 연산자를 읽을 때 '그러한 것'이라고 말합니다.

귀하의 예에서 p => p.Age> 16은 "P, p.Age가 16보다 큼"으로 읽습니다.

사실, 나는 linq 시험판 공식 포럼에서이 질문을했고 Anders Hejlsberg는 다음과 같이 대답했습니다.

나는 보통 => 연산자를 "beeses"또는 "for which"로 읽습니다. 예를 들어,
Func f = x => x * 2;
기능 테스트 = c => c. 도시 == "런던";
"x는 x * 2가됩니다"및 "c.City가 London과 같은 c"로 읽습니다.

'가는'한, 그것은 결코 이해가되지 않습니다. 'p'는 아무데도 가지 않습니다.

전화를 통해 누군가에게 코드를 읽는 경우 동료 C # 프로그래머라면 'lambda'라는 단어를 사용합니다. 열 여섯. "

의견에서 Steve Jessop은 변형의 경우 '지도'를 언급하므로 Anders를 예로 들어 보겠습니다.

x => x * 2;

읽을 것이다

x는 x 곱하기 2에 매핑됩니다.

그것은이 경우 '의'것보다 코드의 실제 의도에 훨씬 가깝게 보입니다.

에서 MSDN :

모든 람다 식은 "goes to"로 읽는 람다 연산자 =>를 사용합니다.

전화를 통한 코드 읽기

에릭 리퍼 트 ​​(Eric Lippert)

나는 개인적으로 c => c + 1이라고 말할 것이다. 내가 들었던 몇 가지 변형 :

투영의 경우 (고객 c) => c. 이름 : "고객은 도트 이름을 참조하십시오"

술어의 경우, (고객 c) => c.Age> 21 : "고객은 도트 연령이 21보다 큰 것을 참조하십시오"

나는 항상 "왕 연산자"라고 불렀습니다 :-)

"p보다 나이 p가 16 세 이상"

사람들이 "화살표"라고 말하는 것을 보았습니다.

LINQ 책에서 다음과 같이 말했기 때문에 "goes to"를 사용합니다.

"매핑"은 어떻습니까? 간결하고 논란의 여지없이 더 기술적으로 정확합니다. 다른 대안들. MSDN 페이지에서 암시하는 것처럼 이미 표준이 있지만 적어도 C # 코드의 경우와 같이 사용해야합니다.

"지도"는 내가 선호하는 발음입니다. 수학적으로 말하면 함수는 인수를 반환 값에 "매핑"(함수는 "매핑"이라고도 함) 프로그래밍에서이 용어를 특히 함수 프로그래밍 (특히 람다 미적분학)으로 사용하는 것이 좋습니다. 수학에 매우 가깝습니다. 그것은 문맥 상 언급이없는 것처럼 상태의 변화를 제안하지 않기 때문에 "가다", "가다"등보다 중립적이다.

나는 그것에 대해 많이 생각하지 않았지만 간결하게 "to"라고 말합니다. 짧고 간결하며 변수가 표현식으로 전달됨 을 의미합니다 . 숫자 2 ( "2")와 혼동 될 수 있지만, 말할 때 "ta"와 같이 "to"를 발음하는 경향이 있습니다. 람다를 아는 ​​사람은 아무도 모호하다고 생각한 적이 없습니다 ...

// "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 'lambda-of'e"입니다. "lambda 'c'function 'e"에 집착하고 있지만, 람다는 에큐메니칼 타협이라고 생각합니다. 분석은 다음과 같습니다.

기괴한 답변에 대해서만 좋은 질문입니다. 대부분의 번역은 람다 표현과 다른 의미를 지니고있어 이국적인 해석으로 이어집니다. 오래된 람다 표현 해커로서 .NET 표기법을 무시하고 머리에 람다로 다시 작성하여 거의 아무것도하지 않았 으면합니다.

전화로 코드를 설명하려면 누군가가 코드를 순서대로 기록 할 수 있기를 원합니다. 그것은 물론 문제이지만, 람다 화살표 또는 무엇인가는 아마도 당신이 얻을 수있는 최선이거나 람다 인이지만 람다는 가장 정확합니다.

문제는 접두사 사용법과 전체의 이름을 지정하는 방법과 접두사 장소에서 말할 때 작동하는 것으로 왼쪽 및 오른쪽 부분의 역할을 지정하는 방법입니다.

이것은 너무 제한적인 문제 일 수 있습니다!

"그렇게"를 사용하지 않을 것입니다. 왜냐하면 오른쪽이 왼쪽이 만족해야하는 조건이라는 것을 의미하기 때문입니다. 이것은 왼쪽이 기능 매개 변수로 추상화 된 오른쪽에 대해 말하는 것과는 매우 다릅니다. "모든 람다 식"에 대한 MSDN 설명은 단순히 불쾌 할뿐만 아니라 불쾌합니다.

우리가 얻을 수있는 한 가까이에 있지만 "가는"것에 대해 뭔가를 평가합니다. "가다"는 변환을 의미하지만, c의 표현식으로가는 변수 c는 정확히 없습니다. 함수에 대한 추상화는 조금 애매합니다. 나는 이것에 익숙해 질 수 있지만 여전히 변수의 추상화를 강조하는 무언가를 갈망합니다.

왼쪽은 항상 지금까지 사용 된 경우에 간단한 식별자이므로 [나중에 혼동 될 수있는 확장을 기다립니다], "c => expression"이라고 생각합니다. "c 'lambda-function'expression " '또는"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.

익명 메소드로 이동하므로 코드의 메소드로 이동할 필요가 없습니다!

그 죄송합니다.

솔직히, 나는 머릿속에 "가는 것"을 사용하고 싶지 않지만, 다른 사람들이 그것이 이상해 보인다고 말하는 것을 보았고, 나는 그것을 분명히 할 것이라고 생각했습니다.

람다 식은 본질적으로 인라인 함수의 구문 설탕입니다 (앞의 범위를 얻는 것 외에도 (람다식이 발생하는 지점에서 정상적인 코드 행에 대한 범위에있는 모든 변수 및 상수는 식의 코드에 사용 가능)) 람다.

생산 연산자 왼쪽의 값 목록 ( "=>")은이 함수를 호출하는 데 사용되는 스택 프레임의 구조와 내용을 제공합니다. 값 목록이 매개 변수 선언과 전달 된 인수 모두에 영향을 준다고 말할 수 있습니다. 보다 일반적인 코드에서 이들은 함수를 호출하는 데 사용되는 스택 프레임의 구조와 내용을 결정합니다.

결과적으로 값은 표현식 코드로 "이동"합니다. "스택 프레임을 정의합니다"또는 "가기"라고 말 하시겠습니까? :)

필터 조건 (이 질문에 대한 다른 답변에서 광범위하게 고려되는 람다 식의 지배적 인 사용)으로 사용되는 부울 식의 좁게 정의 된 응용에서는 코드의 의도에 따라이 방법을 건너 뛰는 것이 매우 합리적입니다. "간결한 것처럼 코드의 의미에 대해 더 많은 것을 말하십시오.

그러나 람다 표현은 Linq의 유일한 주가 아니며이 문맥 외부에서보다 일반적인 형태의 "가는"을 사용해야합니다.

그러나 왜 "가는"?

"다음 코드의 스택 프레임을 채운다"는 말이 너무 길기 때문입니다. 나는 당신이 "통과되었다"고 말할 수 있다고 생각합니다.

명시 적으로 전달 된 매개 변수와 캡처 된 변수 사이의 중요한 차이점은 (올바르게 기억하면 잘못하면 수정하십시오) 전자는 참조로 전달되고 후자는 값으로 전달된다는 것입니다.

문제의 일부는 구조에 따라 다르게 읽을 수 있다는 것입니다. 루비의 것만 큼 예쁘거나 통합되지 않은 것은 부끄러운 일입니다.

루비에서는 이와 동일한 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; };

=>는 지름길이기 때문에 delegate 키워드를 사용할 필요가 없으며 컴파일러가 유추 할 수 있기 때문에 타입 정보를 포함 할 필요가 없습니다.

표시된 결과에 적용된 =>에 대한 내 용어

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

s.Age가 12보다 크고 s.Age가 20보다 작은 경우

'result = x => x * 2'

x에 x에 2를 곱한 값

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

c. c.city는 "런던"과 같습니다.

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

n 여기서 n은 빈 문자열입니다.