두 숫자 (또는 다른 잘 정렬 된 엔티티)를 비교하려면을 사용하십시오 x < y. 세 가지를 비교하고 싶다면 고등학교 대 수생이 시도해볼 것을 제안 x < y < z합니다. 그러면 프로그래머가 "아니요, 유효하지 않습니다 x < y && y < z. 해야합니다 "라고 응답합니다 .

내가 접한 대부분의 언어는이 구문을 지원하지 않는 것 같습니다. 수학에서 얼마나 자주 사용되는지는 이상합니다. 파이썬은 예외입니다. JavaScript 는 예외처럼 보이지만 실제로는 연산자 우선 순위와 암시 적 변환의 불행한 부산물입니다. Node.js를 년 1 < 3 < 2에 평가 true정말 때문에, (1 < 3) < 2 === true < 2 === 1 < 2.

그래서 내 질문은 이것입니다 : 왜 x < y < z예상되는 의미론을 가진 프로그래밍 언어에서 일반적으로 사용할 수 없습니까?

이진 연산자는 체인으로 연결될 때 일반적으로 자연스럽게 다음과 같은 추상 구문 트리를 생성합니다.

평가 (잎에서 수행)하면에서 부울 결과가 생성 x < y되고 유형 오류가 발생 boolean < z합니다. 위해에 대한 x < y < z작업을하려면, 당신은 같은 구문 트리를 생성하는 컴파일러에 특별한 경우를 만들어야합니다 논의 :

그렇게 할 수는 없습니다. 분명히 그렇습니다.하지만 실제로 자주 나오지 않는 경우 파서에 약간의 복잡성이 추가됩니다. 기본적으로 때때로 이진 연산자처럼 작동하고 때로는 삼항 연산자처럼 효과적으로 작동하는 기호를 만들고 있습니다. 오류 처리와 관련된 모든 영향이 수반됩니다. 따라서 언어 디자이너가 가능한 한 피하는 것이 잘못 될 수있는 공간이 많이 있습니다.

x < y < z프로그래밍 언어에서 일반적으로 사용할 수없는 이유는 무엇 입니까?

이 답변에서 나는 결론

• 이 구문은 언어 문법으로 구현하기가 쉽지만 언어 사용자에게 가치를 창출하지만,
• 이것이 대부분의 언어에 존재하지 않는 주된 이유는 다른 기능과 관련하여 언어의 중요성과 언어 관리 기관의 의지가 없기 때문입니다.
  • 잠재적으로 주요 변경 사항이있는 사용자를 화나게 함
  • 기능을 구현하기 위해 이동합니다 (예 : 게으름).

소개

이 질문에 대해 파이썬리스트의 관점에서 말할 수 있습니다. 이 기능을 가진 언어의 사용자이며 언어의 구현 세부 사항을 연구하고 싶습니다. 이 외에도 C 및 C ++ (ISO 표준은위원회가 관리하고 연도별로 버전이 지정됨)와 같은 언어를 변경하는 프로세스에 어느 정도 익숙하며 Ruby와 Python이 주요 변경 사항을 구현하는 것을 보았습니다.

파이썬의 문서와 구현

문서 / 문법에서 비교 연산자를 사용하여 여러 표현식을 연결할 수 있음을 알 수 있습니다.

comparison    ::=  or_expr ( comp_operator or_expr )*
comp_operator ::=  "<" | ">" | "==" | ">=" | "<=" | "!="
                   | "is" ["not"] | ["not"] "in"

그리고 문서에는 다음과 같이 명시되어 있습니다.

비교는 임의로 연결될 수 있습니다. 예를 들어, x <y <= z는 y가 한 번만 평가된다는 점을 제외하고 x <y 및 y <= z와 같습니다 (두 경우 모두 x <y가 발견 될 때 z는 전혀 평가되지 않음) 거짓).

논리적 동등성

그래서

result = (x < y <= z)

논리적으로 동등한 평가의 측면에서 x, y그리고 z제외한 y회 평가 :

x_lessthan_y = (x < y)
if x_lessthan_y:       # z is evaluated contingent on x < y being True
    y_lessthan_z = (y <= z)
    result = y_lessthan_z
else:
    result = x_lessthan_y

다시, 차이점은 y로 y를 한 번만 평가한다는 것입니다 (x < y <= z).

(괄호는 완전히 불필요하고 중복되지만 다른 언어에서 온 사람들의 이익을 위해 사용했으며 위의 코드는 합법적 인 Python입니다.)

구문 분석 된 추상 구문 트리 검사

파이썬이 체인 비교 연산자를 구문 분석하는 방법을 검사 할 수 있습니다.

>>> import ast
>>> node_obj = ast.parse('"foo" < "bar" <= "baz"')
>>> ast.dump(node_obj)
"Module(body=[Expr(value=Compare(left=Str(s='foo'), ops=[Lt(), LtE()],
 comparators=[Str(s='bar'), Str(s='baz')]))])"

따라서 파이썬이나 다른 언어로는 파싱하기가 어렵지 않다는 것을 알 수 있습니다.

>>> ast.dump(node_obj, annotate_fields=False)
"Module([Expr(Compare(Str('foo'), [Lt(), LtE()], [Str('bar'), Str('baz')]))])"
>>> ast.dump(ast.parse("'foo' < 'bar' <= 'baz' >= 'quux'"), annotate_fields=False)
"Module([Expr(Compare(Str('foo'), [Lt(), LtE(), GtE()], [Str('bar'), Str('baz'), Str('quux')]))])"

현재 허용되는 답변과 달리 삼항 연산은 일반 비교 연산으로, 첫 번째 표현식, 특정 비교의 반복 가능 및 필요에 따라 평가할 수있는 표현 노드의 반복 가능을 취합니다. 단순한.

파이썬에 대한 결론

필자는 개인적으로 범위 의미가 매우 우아하다는 것을 알고 있으며, 내가 아는 대부분의 Python 전문가는 기능을 손상시키는 대신 고려하여 기능의 사용을 권장합니다.

코드는 작성된 것보다 훨씬 많이 읽습니다. Fear, Uncertainty 및 Doubt 의 일반 관중을 키우면 코드의 가독성을 향상시키는 변경 사항이 적용되지 않아야합니다 .

그렇다면 왜 프로그래밍 언어에서 x <y <z를 사용할 수 없습니까?

나는 기능의 상대적 중요성과 언어 총재가 허용하는 변화의 운동량 / 관성을 중심으로하는 이유의 합류가 있다고 생각합니다.

다른 중요한 언어 기능에 대해서도 비슷한 질문을 할 수 있습니다

Java 또는 C #에서 다중 상속을 사용할 수없는 이유는 무엇입니까? 여기서 어느 쪽의 질문에 대한 답은 없습니다 . Bob Martin이 주장한 것처럼 개발자가 너무 게으른 것일 수 있으며 주어진 이유는 단지 변명 일뿐입니다. 그리고 다중 상속은 컴퓨터 과학에서 매우 큰 주제입니다. 연산자 체인보다 확실히 중요합니다.

간단한 해결 방법이 있습니다

비교 연산자 체인은 우아하지만 다중 상속만큼 중요한 것은 아닙니다. Java와 C #에서 해결 방법으로 인터페이스를 사용하는 것처럼 여러 비교를위한 모든 언어도 마찬가지입니다. 비교를 부울 "and"로 연결하면 쉽게 작동합니다.

대부분의 언어는위원회가 관리합니다

대부분의 언어는 (파이썬과 같이 현명한 자비로운 독재자가 아닌)위원회에 의해 발전하고 있습니다. 그리고 저는이 문제가 각위원회에서이를 해결하기에 충분한지지를 얻지 못했다고 추측합니다.

이 기능을 제공하지 않는 언어가 변경 될 수 있습니까?

언어 x < y < z가 예상되는 수학적 의미론없이 허용된다면 , 이것은 중대한 변화 일 것입니다. 처음부터 허용하지 않으면 거의 추가하기가 쉽지 않습니다.

주요 변경 사항

주요 변경 사항이있는 언어와 관련하여 : Google은 주요 변경 사항이있는 언어를 업데이트하지만 사용자는 특히 좋아하지 않는 기능의 사용자를 좋아하지 않는 경향이 있습니다. 사용자가의 이전 행동에 의존하고 있다면 x < y < z크게 항의 할 것입니다. 그리고 대부분의 언어가위원회에 의해 지배되기 때문에 그러한 변화를지지 할 정치적 의지를 많이 얻지 못할 것입니다.

컴퓨터 언어는 가능한 가장 작은 단위를 정의하고 조합 할 수 있도록합니다. 가능한 가장 작은 단위는 "x <y"와 같으며 부울 결과를 제공합니다.

삼항 연산자를 요청할 수 있습니다. 예는 x <y <z입니다. 이제 어떤 연산자 조합을 허용합니까? 분명히 x> y> z 또는 x> = y> = z 또는 x> y> = z 또는 x == y == z가 허용되어야합니다. x <y> z는 어떻습니까? x! = y! = z? 마지막 것은 x! = y 및 y! = z 또는 무엇을 의미합니까?

이제 인수 승격 : C 또는 C ++에서 인수는 공통 유형으로 승격됩니다. 그렇다면 x <y <z의 의미는 x의 두 배이지만 y와 z는 긴 정수입니다. 세 사람 모두 두 배로 승진 했습니까? 아니면 y는 두 배로, 다른 시간은 오래 걸리나요? C ++에서 연산자 중 하나 또는 둘 다에 과부하가 걸리면 어떻게됩니까?

마지막으로 피연산자 수를 허용합니까? <b> c <d> e <f> g처럼?

글쎄, 그것은 모두 매우 복잡해집니다. 이제 마음에 들지 않는 것은 구문 오류를 생성하는 x <y <z입니다. 그것의 유용성은 x <y <z가 실제로 무엇을하는지 알 수없는 초보자들에 대한 피해에 비해 작기 때문입니다.

많은 프로그래밍 언어에서 x < y두 개의 피연산자를 허용 하고 단일 부울 결과로 평가 되는 이진 식입니다 . 따라서, 복수의 표현을 체인, 경우 true < z와 false < z의미를, 그 표현이 성공적으로 평가되는 경우, 그들은 가능성이 잘못된 결과를 얻을 수있는 좋은 방법입니다하지 않습니다.

두 개의 매개 변수를 사용하고 단일 부울 결과를 생성하는 함수 호출x < y 로 생각하는 것이 훨씬 쉽습니다 . 실제로, 그것은 많은 언어가 그것을 구현하는 언어입니다. 컴포지션 가능하고 쉽게 컴파일 가능하며 작동합니다.

x < y < z시나리오는 훨씬 더 복잡하다. 이제 컴파일러는, 효과, 패션이 세 가지 기능 : x < y, y < z, 그 두 값의 결과는 전혀 틀림의 컨텍스트 내에서, AND로 모호한 언어 문법 .

왜 다른 방법으로 했습니까? 모호하지 않은 문법이기 때문에 구현하기가 훨씬 쉽고 정확하기가 훨씬 쉽습니다.

대부분의 주류 언어는 (적어도 부분적으로) 객체 지향적입니다. 기본적으로 OO의 기본 원칙은 객체가 다른 객체 (또는 자신)에게 메시지를 보내고 해당 메시지 의 수신자 가 해당 메시지에 응답하는 방법을 완전히 제어한다는 것입니다.

자, 우리가 어떻게 구현할 것인지 봅시다

a < b < c

왼쪽에서 오른쪽으로 엄격하게 평가할 수 있습니다 (왼쪽 연관).

a.__lt__(b).__lt__(c)

그러나 이제 우리 __lt__는의 결과를 요구 a.__lt__(b)합니다 Boolean. 말이되지 않습니다.

올바른 연관성을 시도해 봅시다.

a.__lt__(b.__lt__(c))

아니, 그건 말도 안돼 이제, 우리는 a < (something that's a Boolean).

좋아, 그것을 설탕으로 취급하는 것은 어떻습니까? 일련의 n 개의 <비교가 n-1-ary 메시지를 보내도록 합시다 . 이것은 우리에게 메시지 __lt__를 a전달 b하고 c인수로 전달 한다는 것을 의미 할 수 있습니다 .

a.__lt__(b, c)

좋아, 작품,하지만 이상한 비대칭은 여기있다 : a그것보다 작은 지 여부를 결정 얻는다 b. 그러나 b그것보다 작은 지 여부를 결정하지 않는 c결정이되는 대신에 있음을, 또한 에 의해 만들어진 a.

n-ary 메시지 보내기로 해석하는 것은 this어떻습니까?

this.__lt__(a, b, c)

마침내! 이것은 효과가 있습니다. 그러나 객체의 순서는 더 이상 객체 의 속성이 아니고 (예를 들어 속성의 속성 a보다 적거나 b같지 않은 ) 컨텍스트 의 속성 (즉, )입니다.abthis

주류 관점에서 보면 이상해 보입니다. 그러나 Haskell에서는 정상입니다. Ord예를 들어 typeclass에는 여러 가지 다른 구현이있을 수 있으며 , a보다 작은 지 여부 는 btypeclass 인스턴스가 범위에 속 하는지 여부 에 따라 다릅니다.

그러나 실제로는 그렇지 않아 그 전혀 이상한! Java ( Comparator) 및 .NET ( IComparer)에는 정렬 알고리즘에 자신의 순서 관계를 주입 할 수있는 인터페이스가 있습니다. 따라서 그들은 순서가 유형에 고정되는 것이 아니라 컨텍스트에 의존한다는 것을 완전히 인정합니다.

내가 아는 한, 현재 그러한 번역을 수행하는 언어는 없습니다. 그러나 우선 순위가 있습니다. Ioke 와 Seph 는 디자이너가 " 삼항 연산자"라고 부르는 것 – 구문 적으로 이진이지만 의미 적으로 삼항 인 연산자를가 집니다. 특히,

a = b

되어 있지 메시지를 보내는 것으로 해석 =에 a전달 b인자로, 오히려 같은 메시지를 보내 ="현재 접지"(유사하지만 동일하지는 개념에 this) 전달 a및 b인수로. 따라서 다음과 a = b같이 해석됩니다

=(a, b)

그리고 아닙니다

a =(b)

이것은 n-ary 연산자로 쉽게 일반화 될 수 있습니다.

이것은 실제로 OO 언어에 고유합니다. 오픈 오피스에는 항상 메시지 전송을 해석 할 책임이있는 하나의 단일 객체가 있으며, 우리가 본 것처럼 a < b < c어떤 객체가되어야하는지에 대해서는 즉시 명확하지 않습니다 .

그러나 절차 적 또는 기능적 언어에는 적용되지 않습니다. 예를 들어, Scheme , Common Lisp 및 Clojure 에서 <함수는 n-ary이며 임의의 수의 인수로 호출 할 수 있습니다.

특히, <수행 하지 의미는 "이하", 오히려 이러한 기능은 약간 다르게 해석됩니다 :

(<  a b c d) ; the sequence a, b, c, d is monotonically increasing
(>  a b c d) ; the sequence a, b, c, d is monotonically decreasing
(<= a b c d) ; the sequence a, b, c, d is monotonically non-decreasing
(>= a b c d) ; the sequence a, b, c, d is monotonically non-increasing

언어 디자이너가 생각하지 않았거나 좋은 생각이라고 생각하지 않았기 때문입니다. 파이썬은 간단한 (거의) LL (1) 문법으로 설명 된대로 수행합니다.

다음 C ++ 프로그램은 가능한 가장 높은 수준 ( -Weverything) 으로 경고를 설정 한 경우에도 clang의 neep peep으로 컴파일합니다 .

#include <iostream>
int main () { std::cout << (1 < 3 < 2) << '\n'; }

반면에 gnu 컴파일러 스위트는 저에게 그 사실을 잘 알려줍니다 comparisons like 'X<=Y<=Z' do not have their mathematical meaning [-Wparentheses].

그래서 내 질문은 이것입니다 : 왜 예상되는 의미론을 가지고 x <y <z가 프로그래밍 언어에서 일반적으로 사용 가능하지 않습니까?

대답은 간단합니다 : 이전 버전과의 호환성. 야생에 상당량의 코드가 있으며 그와 동등한 것을 사용 1<3<2하고 결과가 사실이라고 기대합니다.

언어 디자이너는이 "올바른"기능을 얻을 수있는 기회가 한 번 밖에 없으며, 이것이 언어가 처음 설계된 시점입니다. 처음에 "잘못"하게되면 다른 프로그래머들이 그 "잘못된"행동을 빨리 이용하게됩니다. 두 번째로 "올바르게"얻으면 기존 코드 기반이 손상됩니다.