Nếu tôi muốn so sánh hai số (hoặc các thực thể được sắp xếp tốt khác), tôi sẽ làm như vậy với x < y. Nếu tôi muốn so sánh ba trong số họ, học sinh đại số trung học sẽ đề nghị thử x < y < z. Lập trình viên trong tôi sau đó sẽ trả lời "không, điều đó không hợp lệ, bạn phải làm x < y && y < z".

Hầu hết các ngôn ngữ tôi đi qua dường như không hỗ trợ cú pháp này, điều này thật kỳ lạ khi nó phổ biến trong toán học. Python là một ngoại lệ đáng chú ý. JavaScript trông giống như một ngoại lệ, nhưng nó thực sự chỉ là một sản phẩm phụ đáng tiếc của ưu tiên nhà điều hành và chuyển đổi ngầm định; trong node.js, 1 < 3 < 2đánh giá true, bởi vì nó thực sự (1 < 3) < 2 === true < 2 === 1 < 2.

Vì vậy, câu hỏi của tôi là: Tại sao x < y < zkhông phổ biến trong các ngôn ngữ lập trình, với ngữ nghĩa dự kiến?

Đây là các toán tử nhị phân, khi được xâu chuỗi, thông thường và tự nhiên tạo ra một cây cú pháp trừu tượng như:

Khi được đánh giá (mà bạn làm từ lá lên), điều này tạo ra kết quả boolean từ x < yđó, sau đó bạn gặp lỗi loại cố gắng thực hiện boolean < z. Để x < y < zlàm việc như bạn đã thảo luận, bạn phải tạo một trường hợp đặc biệt trong trình biên dịch để tạo ra một cây cú pháp như:

Không phải là không thể làm điều này. Rõ ràng là như vậy, nhưng nó thêm một số phức tạp cho trình phân tích cú pháp cho một trường hợp không thực sự xuất hiện thường xuyên. Về cơ bản, bạn đang tạo một biểu tượng đôi khi hoạt động như một toán tử nhị phân và đôi khi hoạt động hiệu quả như một toán tử ternary, với tất cả các hàm ý của việc xử lý lỗi và do đó đòi hỏi. Điều đó thêm rất nhiều không gian cho những điều sai lầm mà các nhà thiết kế ngôn ngữ sẽ tránh nếu có thể.

Tại sao x < y < zkhông phổ biến trong các ngôn ngữ lập trình?

Trong câu trả lời này, tôi kết luận rằng

• mặc dù cấu trúc này không quan trọng để thực hiện theo ngữ pháp của ngôn ngữ và tạo ra giá trị cho người dùng ngôn ngữ,
• những lý do chính khiến điều này không tồn tại trong hầu hết các ngôn ngữ là do tầm quan trọng của nó so với các tính năng khác và sự không sẵn lòng của các cơ quan quản lý ngôn ngữ đối với một trong hai ngôn ngữ
  • làm người dùng khó chịu với những thay đổi có khả năng phá vỡ
  • để di chuyển để thực hiện tính năng (tức là: sự lười biếng).

Giới thiệu

Tôi có thể nói từ quan điểm của Pythonist về câu hỏi này. Tôi là người sử dụng ngôn ngữ có tính năng này và tôi thích nghiên cứu chi tiết triển khai ngôn ngữ. Ngoài ra, tôi có phần quen thuộc với quá trình thay đổi ngôn ngữ như C và C ++ (tiêu chuẩn ISO được điều chỉnh bởi ủy ban và được phiên bản theo năm.) Và tôi đã xem cả Ruby và Python thực hiện các thay đổi vi phạm.

Tài liệu và cách thực hiện của Python

Từ các tài liệu / ngữ pháp, chúng ta thấy rằng chúng ta có thể xâu chuỗi bất kỳ số lượng biểu thức nào với các toán tử so sánh:

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

và các tài liệu nêu thêm:

Việc so sánh có thể được xâu chuỗi tùy ý, ví dụ: x <y <= z tương đương với x <y và y <= z, ngoại trừ việc y chỉ được đánh giá một lần (nhưng trong cả hai trường hợp z đều không được đánh giá khi tìm thấy x <y là sai).

Tương đương logic

Vì thế

result = (x < y <= z)

là một cách logic tương đương về mặt đánh giá x, yvà z, với ngoại lệ mà yđược đánh giá hai lần:

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

Một lần nữa, sự khác biệt là y chỉ được đánh giá một lần với (x < y <= z) .

(Lưu ý, các dấu ngoặc đơn là hoàn toàn không cần thiết và dư thừa, nhưng tôi đã sử dụng chúng vì lợi ích của những từ đến từ các ngôn ngữ khác và mã trên là Python khá hợp pháp.)

Kiểm tra cây cú pháp trừu tượng

Chúng ta có thể kiểm tra cách Python phân tích các toán tử so sánh chuỗi:

>>> 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')]))])"

Vì vậy, chúng ta có thể thấy rằng điều này thực sự không khó đối với Python hoặc bất kỳ ngôn ngữ nào khác để phân tích.

>>> 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')]))])"

Và trái với câu trả lời hiện đang được chấp nhận, hoạt động ternary là một hoạt động so sánh chung, lấy biểu thức đầu tiên, một phép so sánh cụ thể và một nút lặp của các nút biểu thức để đánh giá khi cần thiết. Đơn giản.

Kết luận về Python

Cá nhân tôi thấy ngữ nghĩa phạm vi khá thanh lịch và hầu hết các chuyên gia Python mà tôi biết sẽ khuyến khích việc sử dụng tính năng này, thay vì xem xét nó có hại - ngữ nghĩa được nêu khá rõ trong tài liệu có uy tín (như đã lưu ý ở trên).

Lưu ý rằng mã được đọc nhiều hơn nó được viết. Những thay đổi giúp cải thiện khả năng đọc mã nên được chấp nhận, không được giảm giá bằng cách tăng các đối tượng chung về Sợ hãi, Không chắc chắn và Nghi ngờ .

Vậy tại sao x <y <z không phổ biến trong các ngôn ngữ lập trình?

Tôi nghĩ rằng có một sự hợp lưu của các lý do xoay quanh tầm quan trọng tương đối của tính năng và động lượng / quán tính tương đối của sự thay đổi được cho phép bởi các thống đốc của các ngôn ngữ.

Các câu hỏi tương tự có thể được hỏi về các tính năng ngôn ngữ quan trọng khác

Tại sao không có nhiều kế thừa có sẵn trong Java hoặc C #? Không có câu trả lời tốt ở đây cho một trong hai câu hỏi . Có lẽ các nhà phát triển đã quá lười biếng, như Bob Martin cáo buộc, và những lý do được đưa ra chỉ là lý do. Và thừa kế nhiều là một chủ đề khá lớn trong khoa học máy tính. Nó chắc chắn quan trọng hơn chuỗi vận hành.

Giải pháp đơn giản tồn tại

Chuỗi toán tử so sánh là thanh lịch, nhưng không có nghĩa là quan trọng như nhiều kế thừa. Và cũng giống như Java và C # có giao diện như một cách giải quyết, mọi ngôn ngữ cho nhiều so sánh - bạn chỉ cần xâu chuỗi các phép so sánh với boolean "và", hoạt động đủ dễ dàng.

Hầu hết các ngôn ngữ được điều chỉnh bởi ủy ban

Hầu hết các ngôn ngữ đang phát triển bởi ủy ban (thay vì có một Nhà độc tài nhân từ hợp lý cho cuộc sống như Python có). Và tôi suy đoán rằng vấn đề này chưa thấy đủ sự hỗ trợ để đưa nó ra khỏi các ủy ban tương ứng.

Các ngôn ngữ không cung cấp tính năng này có thể thay đổi không?

Nếu một ngôn ngữ cho phép x < y < zmà không có ngữ nghĩa toán học dự kiến, đây sẽ là một thay đổi đột phá. Nếu nó không cho phép nó ở nơi đầu tiên, nó sẽ gần như không đáng kể để thêm vào.

Thay đổi đột phá

Về các ngôn ngữ có các thay đổi vi phạm: chúng tôi cập nhật các ngôn ngữ có các thay đổi về hành vi - nhưng người dùng có xu hướng không thích điều này, đặc biệt là người dùng các tính năng có thể bị hỏng. Nếu người dùng đang dựa vào hành vi trước đây x < y < z, họ có thể sẽ phản đối mạnh mẽ. Và vì hầu hết các ngôn ngữ được điều hành bởi ủy ban, tôi nghi ngờ chúng ta sẽ có nhiều ý chí chính trị để hỗ trợ một sự thay đổi như vậy.

Ngôn ngữ máy tính cố gắng xác định các đơn vị nhỏ nhất có thể và cho phép bạn kết hợp chúng. Đơn vị nhỏ nhất có thể sẽ là một cái gì đó như "x <y" mang lại kết quả boolean.

Bạn có thể yêu cầu một nhà điều hành ternary. Một ví dụ sẽ là x <y <z. Bây giờ những sự kết hợp của các nhà khai thác chúng ta cho phép? Rõ ràng x> y> z hoặc x> = y> = z hoặc x> y> = z hoặc có thể x == y == z nên được cho phép. Còn x <y> z thì sao? x! = y! = z? Cái cuối cùng có nghĩa là gì, x! = Y và y! = Z hoặc cả ba đều khác nhau?

Bây giờ khuyến mãi đối số: Trong C hoặc C ++, các đối số sẽ được thăng cấp thành một loại phổ biến. Vậy x <y <z có nghĩa là gì của x là gấp đôi nhưng y và z dài int? Cả ba thăng lên gấp đôi? Hoặc y được lấy gấp đôi một lần và dài như int lần khác? Điều gì xảy ra nếu trong C ++ một hoặc cả hai toán tử bị quá tải?

Và cuối cùng, bạn có cho phép bất kỳ số toán hạng nào không? Giống như một <b> c <d> e <f> g?

Vâng, tất cả trở nên rất phức tạp. Bây giờ điều tôi không bận tâm là x <y <z tạo ra lỗi cú pháp. Bởi vì tính hữu dụng của nó là nhỏ so với thiệt hại gây ra cho người mới bắt đầu, những người không thể tìm ra x <y <z thực sự làm gì.

Trong nhiều ngôn ngữ lập trình, x < ylà một biểu thức nhị phân chấp nhận hai toán hạng và ước lượng cho một kết quả boolean duy nhất. Do đó, nếu xâu chuỗi nhiều biểu thức true < zvà false < zsẽ không có ý nghĩa và nếu những biểu thức đó đánh giá thành công, chúng có khả năng tạo ra kết quả sai.

Sẽ dễ dàng hơn nhiều khi nghĩ về x < ymột cuộc gọi hàm có hai tham số và tạo ra một kết quả boolean duy nhất. Trong thực tế, đó là có bao nhiêu ngôn ngữ thực hiện nó dưới mui xe. Nó có thể kết hợp, dễ dàng biên dịch, và nó chỉ hoạt động.

Các x < y < zkịch bản được nhiều phức tạp. Bây giờ, trình biên dịch, thực tế, phải tạo ra ba chức năng : x < y, y < zvà kết quả của hai giá trị đó được kết hợp với nhau, tất cả nằm trong bối cảnh của một ngữ pháp ngôn ngữ mơ hồ có thể tranh cãi .

Tại sao họ làm theo cách khác? Bởi vì nó là ngữ pháp rõ ràng, dễ thực hiện hơn nhiều và dễ dàng hơn để có được chính xác.

Hầu hết các ngôn ngữ chính là (ít nhất một phần) hướng đối tượng. Về cơ bản, nguyên tắc cơ bản của OO là các đối tượng gửi tin nhắn đến các đối tượng khác (hoặc chính họ) và người nhận tin nhắn đó có toàn quyền kiểm soát cách trả lời tin nhắn đó.

Bây giờ, hãy xem cách chúng tôi sẽ thực hiện một cái gì đó như

a < b < c

Chúng tôi có thể đánh giá nó hoàn toàn từ trái sang phải (liên kết trái):

a.__lt__(b).__lt__(c)

Nhưng bây giờ chúng tôi gọi __lt__kết quả của a.__lt__(b), đó là một Boolean. Điều đó không có ý nghĩa.

Hãy thử kết hợp đúng:

a.__lt__(b.__lt__(c))

Không, điều đó cũng không có ý nghĩa. Bây giờ, chúng tôi có a < (something that's a Boolean).

Được rồi, những gì về việc coi nó là đường cú pháp. Hãy tạo một chuỗi <so sánh n gửi tin nhắn n-1-ary. Điều này có thể có nghĩa là, chúng tôi gửi tin nhắn __lt__đến a, gửi bvà clàm đối số:

a.__lt__(b, c)

Được rồi, nó hoạt động, nhưng có một sự bất cân xứng kỳ lạ ở đây: ađược quyết định liệu nó có ít hơn không b. Nhưng bkhông được quyết định liệu nó có ít hơn hay không c, thay vào đó quyết định đó cũng được đưa ra a.

Điều gì về việc diễn giải nó như một tin nhắn n-ary gửi đến this?

this.__lt__(a, b, c)

Cuối cùng! Điều này có thể làm việc. Tuy nhiên, điều đó có nghĩa là thứ tự của các đối tượng không còn là một thuộc tính của đối tượng (ví dụ: có anhỏ hơn bkhông phải là thuộc tính của ahay không b) mà thay vào đó là một thuộc tính của bối cảnh (nghĩa là this).

Từ một quan điểm chính thống có vẻ kỳ lạ. Tuy nhiên, ví dụ như trong Haskell, điều đó là bình thường. Chẳng hạn, có thể có nhiều cách triển khai khác nhau của kiểu chữ Ord, và việc có anhỏ hơn hay không b, tùy thuộc vào trường hợp kiểu chữ nào xảy ra trong phạm vi.

Nhưng thật ra, nó không có gì lạ cả! Cả Java ( Comparator) và .NET ( IComparer) đều có giao diện cho phép bạn đưa quan hệ đặt hàng của riêng bạn vào các thuật toán sắp xếp. Vì vậy, họ hoàn toàn thừa nhận rằng một đơn đặt hàng không phải là thứ được cố định với một loại mà thay vào đó phụ thuộc vào ngữ cảnh.

Theo tôi biết, hiện tại không có ngôn ngữ nào thực hiện bản dịch như vậy. Tuy nhiên, có một ưu tiên: cả Ioke và Seph đều có cái mà nhà thiết kế của họ gọi là "toán tử nhị phân " - các toán tử có cấu trúc nhị phân, nhưng về mặt ngữ nghĩa . Đặc biệt,

a = b

là không hiểu là gửi tin nhắn =để ađi qua bnhư là đối số, nhưng thay vì như gửi thông điệp =đến "Ground hiện tại" (một khái niệm tương tự nhưng không giống hoàn toàn this) đi qua avà bnhư các đối số. Vì vậy, a = bđược hiểu là

=(a, b)

và không

a =(b)

Điều này có thể dễ dàng được khái quát cho các nhà khai thác n-ary.

Lưu ý rằng điều này thực sự đặc biệt với các ngôn ngữ OO. Trong OO, chúng ta luôn có một đối tượng chịu trách nhiệm chính trong việc diễn giải một tin nhắn gửi, và như chúng ta đã thấy, điều đó không rõ ràng ngay lập tức đối với một thứ giống như a < b < cđối tượng nào nên có.

Điều này không áp dụng cho các ngôn ngữ thủ tục hoặc chức năng mặc dù. Ví dụ, trong Scheme , Common Lisp và Clojure , <hàm này là n-ary và có thể được gọi với số lượng đối số tùy ý.

Đặc biệt, <làm không có nghĩa là "ít hơn", chứ không phải các chức năng này được giải thích hơi khác nhau:

(<  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

Điều đó đơn giản là vì các nhà thiết kế ngôn ngữ đã không nghĩ về nó hoặc không nghĩ rằng đó là một ý tưởng tốt. Python thực hiện nó như bạn đã mô tả với một ngữ pháp đơn giản (gần như) LL (1).

Chương trình C ++ sau đây biên dịch với một peep từ clang, ngay cả với các cảnh báo được đặt ở mức cao nhất có thể ( -Weverything):

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

Mặt khác, bộ biên dịch gnu cảnh báo độc đáo cho tôi điều đó comparisons like 'X<=Y<=Z' do not have their mathematical meaning [-Wparentheses].

Vì vậy, câu hỏi của tôi là: tại sao x <y <z không phổ biến trong các ngôn ngữ lập trình, với ngữ nghĩa dự kiến?

Câu trả lời rất đơn giản: Tương thích ngược. Có một số lượng lớn mã ngoài tự nhiên sử dụng tương đương 1<3<2và mong đợi kết quả là đúng-ish.

Một nhà thiết kế ngôn ngữ có một cơ hội để có được "quyền" này và đó là thời điểm ngôn ngữ được thiết kế lần đầu tiên. Nhận được "sai" ban đầu có nghĩa là các lập trình viên khác sẽ nhanh chóng tận dụng lợi thế của hành vi "sai" đó. Làm cho nó "đúng" lần thứ hai xung quanh sẽ phá vỡ cơ sở mã hiện có.