이 아이디어를 처음 접한 건 Pony였고, 알고 나니 너무나 당연하게 느껴졌음. 특히 or/and 우선순위가 작성자의 예상과 달라 운영 환경에서 큰 피해를 낸 SQL 쿼리를 본 뒤라 더욱 그랬음. RCL에도 도입했으며, 이제 Zig도 채택한다니 반가움!
원래 제안에서 Pony를 명시적으로 인용하고 있음. 제안자는 당시 언어 관련 제안을 꽤 많이 올렸는데, 대부분은 고개를 갸웃하게 했지만 이번 것은 좋은 아이디어로 느껴졌음.
Pony가 +와 *까지 이 원칙을 적용한 건 대단함. 나조차 그 정도까지 밀어붙일 엄두는 나지 않음.
두어 달 전 같은 변경을 위한 Hare 제안을 작성했고, 커뮤니티에서도 대체로 호응을 얻었음. Zig도 같은 변경을 한다니 반가움! 프로그래밍 언어가 이런 부분을 더 엄격하게 다뤄야 할 때는 이미 한참 지났음.
실제로는 모호한 연산자들에 전순서를 부여하는 방식은 오래전부터 골칫거리였음. 내가 만든 프로그래밍 언어는 사용자가 구문을 확장할 수 있어서 우선순위 DAG로 이를 구현함. 관련 문헌은 precedence DAG로 검색할 수 있지만, 부분 순서가 무엇인지는 직관적으로 이해할 수 있을 듯함.
사용자 확장 문법도 설치 시점에 모호성 여부를 판정할 수 있으므로, 모호한 문법 자체를 만들 수 없게 되어 있음.
모든 언어에 보편적으로 도입해야 한다고 할 만큼 좋은 아이디어임. 나도 평소 비슷한 규칙을 따르며, 필요하지 않은 곳에도 괄호를 자주 사용함.
궁금한 건 파서에서의 구현 방식임. 전통적인 연산자 우선순위는 expr[0]의 자식을 expr[1]로 두는 식으로, 우선순위 단계가 올라갈 때마다 허용되는 연산자를 제한하면 되므로 구현이 쉬움. 이 방식을 부분 순서에는 어떻게 적용할 수 있을까?
우선순위 단계 수를 줄이는 것과 비교하면 어떤 이점이 있을까?
우선순위 단계 수를 줄여도 프로그래머가 알아야 할 정보량은 줄지 않고, 알아야 할 내용만 바뀜. 게다가 기존 코드의 동작을 아무 경고 없이 바꾸는 호환성 파괴가 됨.
비트 연산자는 어디에 놓아야 할까? 덧셈·뺄셈과 같은 단계인지, 곱셈·나눗셈과 같은 단계인지, 아니면 양쪽에 나눠 배치할지 결정해야 함. 결국 a | b + c, a << b + c, a | b * c, a | b << c 등을 어떻게 평가할 것인지의 문제임.
참고로 변경 전 우선순위 표는 여기서 볼 수 있음.