หากฉันต้องการเปรียบเทียบตัวเลขสองตัว (หรือเอนทิตีที่มีการจัดลำดับที่ดีอื่น ๆ ) ฉันจะทำเช่นx < yนั้น ถ้าผมต้องการเปรียบเทียบสามของพวกเขา, x < y < zนักเรียนพีชคณิตโรงเรียนมัธยมจะแนะนำพยายาม โปรแกรมเมอร์ในตัวฉันจะตอบกลับด้วย "ไม่นั่นไม่ถูกต้องคุณต้องทำx < y && y < z"

ภาษาส่วนใหญ่ที่ฉันพบเจอดูเหมือนจะไม่สนับสนุนไวยากรณ์นี้ซึ่งเป็นเรื่องแปลกเพราะมันเป็นเรื่องธรรมดาในวิชาคณิตศาสตร์ Python เป็นข้อยกเว้นที่น่าสังเกต JavaScript ดูเหมือนข้อยกเว้น แต่จริงๆแล้วเป็นเพียงผลพลอยได้ที่โชคร้ายของลำดับความสำคัญของผู้ปฏิบัติงานและการแปลงโดยนัย ใน Node.js, 1 < 3 < 2ประเมินเพราะมันจริงๆtrue(1 < 3) < 2 === true < 2 === 1 < 2

ดังนั้นคำถามของฉันคือ: เหตุใดจึงx < y < zไม่มีอยู่ทั่วไปในภาษาการเขียนโปรแกรมด้วยความหมายที่คาดหวัง

สิ่งเหล่านี้เป็นตัวดำเนินการแบบไบนารีซึ่งเมื่อถูกล่ามโซ่โดยปกติและเป็นธรรมชาติจะสร้างต้นไม้ที่เป็นนามธรรมเช่น:

เมื่อประเมินผล (ซึ่งคุณทำจากใบขึ้นไป) นี้ผลิตเป็นผลมาจากบูลแล้วคุณจะได้รับข้อผิดพลาดประเภทพยายามที่จะทำx < y boolean < zเพื่อให้x < y < zสามารถทำงานได้ตามที่กล่าวไว้คุณจะต้องสร้างเคสพิเศษในคอมไพเลอร์เพื่อสร้างแผนผังไวยากรณ์เช่น:

ไม่ใช่ว่ามันเป็นไปไม่ได้ที่จะทำเช่นนี้ เห็นได้ชัดว่ามันเป็น แต่มันเพิ่มความซับซ้อนบางอย่างเพื่อ parser สำหรับกรณีที่ไม่ได้เกิดขึ้นบ่อยครั้งที่ คุณมักจะสร้างสัญลักษณ์ที่บางครั้งทำหน้าที่เหมือนตัวดำเนินการแบบไบนารีและบางครั้งก็ทำหน้าที่ได้อย่างมีประสิทธิภาพเหมือนตัวดำเนินการที่ประกอบไปด้วยผลกระทบทั้งหมดของการจัดการข้อผิดพลาด นั่นเป็นการเพิ่มพื้นที่สำหรับสิ่งผิดพลาดที่นักออกแบบภาษาจะหลีกเลี่ยงหากเป็นไปได้

เหตุใดจึงx < y < zไม่มีอยู่ทั่วไปในภาษาการเขียนโปรแกรม

ในคำตอบนี้ฉันสรุปได้ว่า

• แม้ว่าโครงสร้างนี้เป็นเรื่องเล็กน้อยที่จะนำไปใช้ในไวยากรณ์ของภาษาและสร้างคุณค่าให้กับผู้ใช้ภาษา
• เหตุผลหลักที่ว่าสิ่งนี้ไม่ได้มีอยู่ในภาษาส่วนใหญ่เกิดจากความสำคัญของมันที่เกี่ยวข้องกับคุณสมบัติอื่น ๆ และความไม่เต็มใจของหน่วยงานการปกครองของภาษาทั้ง
  • ทำให้ผู้ใช้อารมณ์เสียด้วยการเปลี่ยนแปลงที่อาจเกิดขึ้น
  • เพื่อย้ายไปใช้คุณลักษณะ (เช่น: ความเกียจคร้าน)

บทนำ

ฉันสามารถพูดได้จากมุมมองของ Pythonist กับคำถามนี้ ฉันเป็นผู้ใช้ภาษาที่มีคุณสมบัตินี้และฉันชอบศึกษารายละเอียดการใช้ภาษา นอกเหนือจากนี้ฉันค่อนข้างคุ้นเคยกับกระบวนการเปลี่ยนภาษาเช่น C และ C ++ (มาตรฐาน ISO อยู่ภายใต้การควบคุมของคณะกรรมการและเวอร์ชันปี) และฉันได้ดูทั้ง Ruby และ Python ใช้การเปลี่ยนแปลงที่ทำลาย

เอกสารและการใช้งานของไพ ธ อน

จากเอกสาร / ไวยากรณ์เราเห็นว่าเราสามารถเชื่อมโยงนิพจน์จำนวนเท่าใดก็ได้กับตัวดำเนินการเปรียบเทียบ:

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

และเอกสารประกอบระบุเพิ่มเติม:

การเปรียบเทียบสามารถถูกล่ามโซ่โดยพลการตัวอย่างเช่น x <y <= z เทียบเท่ากับ x <y และ y <= z ยกเว้นว่า y ถูกประเมินเพียงครั้งเดียว (แต่ในทั้งสองกรณี z ไม่ได้รับการประเมินเลยเมื่อพบ x <y เป็นเท็จ)

สมการเชิงตรรกะ

ดังนั้น

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

(x < y <= z)อีกครั้งที่แตกต่างคือปีได้รับการประเมินเพียงครั้งเดียวด้วย

(หมายเหตุวงเล็บไม่จำเป็นและซ้ำซ้อน แต่ฉันใช้มันเพื่อประโยชน์ของผู้ที่มาจากภาษาอื่นและรหัสข้างต้นค่อนข้างถูกต้องตามกฎหมายของ Python)

การตรวจสอบทรีไวยากรณ์แยกวิเคราะห์

เราสามารถตรวจสอบว่า 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')]))])"

ดังนั้นเราจะเห็นได้ว่านี่ไม่ใช่เรื่องยากที่ Python หรือภาษาอื่นจะแยกวิเคราะห์

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

ฉันพบว่าความหมายของช่วงนั้นค่อนข้างจะหรูหราและผู้เชี่ยวชาญ Python ส่วนใหญ่ที่ฉันรู้จักจะสนับสนุนการใช้งานคุณลักษณะนี้แทนที่จะพิจารณาว่าเป็นความเสียหาย - ความหมายนั้นมีการระบุไว้อย่างชัดเจนในเอกสารที่มีชื่อเสียง

โปรดทราบว่ามีการอ่านรหัสมากกว่าที่เขียนไว้ การเปลี่ยนแปลงที่ปรับปรุงการอ่านรหัสที่ควรได้รับการกอดไม่ลดโดยการเพิ่มภูตผีทั่วไปของความกลัวความไม่แน่นอนและไม่ต้องสงสัยเลย

แล้วเหตุใด x <y <z จึงไม่มีอยู่ทั่วไปในภาษาการเขียนโปรแกรม

ฉันคิดว่ามีการรวมกันของเหตุผลที่มุ่งเน้นไปที่ความสำคัญของคุณลักษณะและโมเมนตัม / ความเฉื่อยของการเปลี่ยนแปลงที่ได้รับอนุญาตโดยผู้ว่าราชการของภาษา

คำถามที่คล้ายกันสามารถถามเกี่ยวกับคุณสมบัติภาษาที่สำคัญอื่น ๆ

เหตุใดจึงไม่มีการสืบทอดหลายรายการใน Java หรือ C # ไม่มีคำตอบที่ดีสำหรับคำถามนี้ บางทีนักพัฒนาอาจขี้เกียจเกินไปอย่างที่บ็อบมาร์ตินอ้างเหตุผลและเหตุผลก็เป็นข้อแก้ตัว และการสืบทอดหลายครั้งเป็นหัวข้อที่ยิ่งใหญ่ในสาขาวิทยาศาสตร์คอมพิวเตอร์ มีความสำคัญมากกว่าการผูกมัดผู้ปฏิบัติงานอย่างแน่นอน

มีวิธีแก้ไขปัญหาง่าย ๆ อยู่

การโยงผู้ประกอบการเปรียบเทียบนั้นสง่างาม แต่ก็ไม่สำคัญเท่ากับมรดกหลายอย่าง และเช่นเดียวกับ Java และ C # มีอินเทอร์เฟซเป็นวิธีแก้ปัญหาดังนั้นทุกภาษาสำหรับการเปรียบเทียบหลาย ๆ ครั้ง - คุณเพียงเชื่อมโยงการเปรียบเทียบกับบูลีน "และ" s ซึ่งทำงานได้ง่ายพอ

ภาษาส่วนใหญ่ควบคุมโดยคณะกรรมการ

ภาษาส่วนใหญ่มีการพัฒนาโดยคณะกรรมการ (แทนที่จะมีเผด็จการใจดีสำหรับชีวิตเหมือนงูใหญ่มี) และฉันคาดการณ์ว่าปัญหานี้เพิ่งไม่ได้เห็นการสนับสนุนเพียงพอที่จะทำให้มันออกมาจากคณะกรรมการที่เกี่ยวข้อง

ภาษาที่ไม่มีคุณสมบัตินี้สามารถเปลี่ยนแปลงได้หรือไม่?

หากภาษายอมให้x < y < zไม่มีความหมายทางคณิตศาสตร์ที่คาดหวังนี่จะเป็นการเปลี่ยนแปลงที่ไม่คาดคิด หากไม่อนุญาตให้ใช้ในตอนแรกมันจะเพิ่มขึ้นเล็กน้อย

ทำลายการเปลี่ยนแปลง

เกี่ยวกับภาษาที่มีการเปลี่ยนแปลงที่ไม่หยุดยั้ง: เราอัปเดตภาษาที่มีการเปลี่ยนแปลงพฤติกรรมที่ไม่ปกติ - แต่ผู้ใช้มักจะไม่ชอบสิ่งนี้โดยเฉพาะผู้ใช้คุณสมบัติที่อาจใช้งานไม่ได้ หากผู้ใช้พึ่งพาพฤติกรรมเดิมของ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 นั้นมีความยาว int? ทั้งสามได้รับการเลื่อนตำแหน่งเป็นสองเท่า? หรือว่า y ถูกจับเป็นสองเท่าหนึ่งครั้งและนาน int อีกครั้ง? จะเกิดอะไรขึ้นถ้าใน 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และผลของทั้งสองค่า ANDed กันทั้งหมดภายในบริบทของเนื้อหาไวยากรณ์ภาษาคลุมเครือ

ทำไมพวกเขาถึงทำอย่างอื่น? เพราะมันเป็นไวยากรณ์ที่ชัดเจนง่ายต่อการใช้และง่ายต่อการแก้ไขให้ถูกต้อง

ภาษากระแสหลักส่วนใหญ่ (อย่างน้อยบางส่วน) เชิงวัตถุ หลักการพื้นฐานของ 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 ส่ง 1-n-ary นี่อาจหมายถึงเราส่งข้อความ__lt__ไปให้aผ่านbและcเป็นข้อโต้แย้ง:

a.__lt__(b, c)

โอเคทำงานได้ แต่มีความไม่สมดุลแปลก ๆ ที่นี่: aตัดสินใจว่ามันจะน้อยกว่าbหรือเปล่า แต่bไม่ได้รับการตัดสินใจไม่ว่าจะเป็นน้อยกว่าcแทนว่าการตัดสินใจจะยังaทำโดย

สิ่งที่เกี่ยวกับการตีความมันเป็นข้อความที่ส่งไปยัง nary this?

this.__lt__(a, b, c)

ที่สุด! สิ่งนี้สามารถทำงานได้ มันหมายถึงว่าการเรียงลำดับของวัตถุนั้นไม่ใช่สมบัติของวัตถุอีกต่อไป (เช่นว่าaน้อยกว่าbจะไม่ใช่สมบัติของaหรือของb) แต่แทนที่จะเป็นสมบัติของบริบท (เช่นthis)

จากมุมมองหลักที่ดูแปลก ๆ อย่างไรก็ตามเช่นใน Haskell นั่นเป็นเรื่องปกติ สามารถมีการใช้งานที่แตกต่างกันหลายอย่างของOrdtypeclass เช่นและไม่ว่าaจะน้อยกว่าหรือไม่bขึ้นอยู่กับอินสแตนซ์ของ typeclass ที่เกิดขึ้นในขอบเขต

แต่จริงๆแล้วมันไม่ได้เป็นที่แปลกที่ทุกคน! ทั้ง Java ( Comparator) และ. NET ( IComparer) มีอินเทอร์เฟซที่ช่วยให้คุณสามารถฉีดความสัมพันธ์ในการสั่งซื้อของคุณเองลงไปเช่นขั้นตอนวิธีการเรียงลำดับ ดังนั้นพวกเขายอมรับอย่างเต็มที่ว่าการสั่งซื้อไม่ใช่สิ่งที่ถูกกำหนดเป็นประเภท แต่ขึ้นอยู่กับบริบท

เท่าที่ฉันรู้ในปัจจุบันไม่มีภาษาที่ใช้ทำการแปลดังกล่าว อย่างไรก็ตามมีความสำคัญกว่า: ทั้งIokeและSephมีสิ่งที่นักออกแบบเรียกว่า "ตัวดำเนินการ trinary" - ตัวดำเนินการซึ่งเป็นไบนารีsyntacticallyแต่มีความหมายสามส่วน โดยเฉพาะอย่างยิ่ง,

a = b

จะไม่ได้ตีความว่าการส่งข้อความ=เพื่อaส่งผ่านbเป็นอาร์กิวเมนต์ แต่การส่งข้อความ=ไปที่ "กราวนด์ในปัจจุบัน" (แนวคิดที่คล้ายกัน แต่ไม่เหมือนกันthis) ผ่านaและbเป็นข้อโต้แย้ง ดังนั้นจึงa = bตีความได้ว่า

=(a, b)

และไม่

a =(b)

สิ่งนี้สามารถนำไปใช้กับผู้ประกอบการ n-ary ได้อย่างง่ายดาย

โปรดทราบว่านี่เป็นเรื่องแปลกสำหรับภาษา OO ใน OO เรามักจะมีวัตถุหนึ่งชิ้นซึ่งท้ายที่สุดรับผิดชอบในการตีความการส่งข้อความและในขณะที่เราได้เห็นมันไม่ชัดเจนในทันทีสำหรับบางสิ่งเช่นa < b < cวัตถุที่ควรจะเป็น

สิ่งนี้ไม่ได้ใช้กับขั้นตอนหรือภาษาที่ใช้งานได้ ยกตัวอย่างเช่นในโครงการ , Common เสียงกระเพื่อมและ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

เป็นเพราะนักออกแบบภาษาไม่ได้คิดหรือไม่คิดว่ามันเป็นความคิดที่ดี Python ทำตามที่คุณอธิบายด้วยไวยากรณ์ (เกือบ) LL (1) อย่างง่าย

โปรแกรม C ++ ต่อไปนี้คอมไพล์ด้วย nary peep จากเสียงดังกราวแม้จะมีคำเตือนตั้งไว้ในระดับสูงสุดที่เป็นไปได้ ( -Weverything):

#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 โดยทั่วไปไม่สามารถใช้งานได้ในภาษาโปรแกรมด้วยซีแมนทิกส์ที่คาดหวัง?

คำตอบนั้นง่าย: ความเข้ากันได้ย้อนหลัง มีโค้ดจำนวนมากอยู่ใน wild ที่ใช้สิ่งที่เทียบเท่า1<3<2และคาดว่าผลลัพธ์จะเป็นจริง

นักออกแบบภาษามี แต่โอกาสเดียวที่จะได้รับ "สิทธิ" นี้และนั่นคือจุดที่เวลาที่ภาษาได้รับการออกแบบครั้งแรก เริ่มแรกให้ "ผิด" หมายความว่าโปรแกรมเมอร์คนอื่นจะใช้ประโยชน์จากพฤติกรรมที่ "ผิด" อย่างรวดเร็ว การทำให้ "ถูกต้อง" ในครั้งที่สองจะทำให้ฐานรหัสนั้นเสียหาย