เอกสารข้อกำหนดใหม่สำหรับ S-expressions ได้นำเสนอส่วนขยายที่ก่อให้เกิดความขัดแย้งซึ่งท้าทายหลักการไวยากรณ์การเขียนโปรแกรมแบบดั้งเดิมอย่างมูลฐาน ไลบรารี S-expr เสนอให้เพิ่มสตริงหลายบรรทัด คอมเมนต์ และที่น่าสนใจที่สุดคือบล็อกแบบ transposed ที่ช่วยให้สามารถเขียนโค้ดในรูปแบบเลย์เอาต์สองมิติด้วยการจัดเรียงแนวตั้งและแนวนอน
เอกสารที่มุ่งเป้าไปที่ผู้เริ่มต้นเรียนการเขียนโปรแกรมนี้แนะนำว่าส่วนขยายเหล่านี้สามารถปรับปรุงความสามารถในการอ่านโค้ดได้โดยการแก้ไขปัญหาทั่วไปของวงเล็บซ้อนกันในภาษาสไตล์ Lisp อย่างไรก็ตาม การตอบสนองจากชุมชนนักเขียนโปรแกรมส่วนใหญ่มีความสงสัยอย่างมาก
การเปรียบเทียบไวยากรณ์ของสตริง
| ประเภท | S-expr แบบดั้งเดิม | S-expr ส่วนขยาย |
|---|---|---|
| สตริงบรรทัดเดียว | "text" |
"text" |
| สตริงหลายบรรทัด | ไม่รองรับ | ***\ntext\n*** |
| คอมเมนต์ | ;comment |
//comment// หรือ ///\ncomment\n/// |
| บล็อก 2D | ไม่รองรับ | *\nvertical\ntext\n* |
หลักการ S-Expression แบบดั้งเดิมถูกท้าทาย
ส่วนขยายที่เสนอมานี้ละเมิดหลักการหลักที่ทำให้ S-expressions ประสบความสำเร็จมาเป็นเวลาหลายทศวรรษ S-expressions แบบดั้งเดิมจะไม่สนใจช่องว่างส่วนใหญ่และสามารถแยกวิเคราะห์แบบเส้นตรงได้โดยไม่ต้องย้อนกลับ โครงสร้าง 2 มิติใหม่นี้ทำลายโมเดลนี้อย่างมูลฐานโดยต้องการให้ parser กระโดดผ่านโค้ดในแนวตั้งและอ่านบล็อกหลายบรรทัดให้เสร็จสิ้นก่อนที่จะดำเนินการต่อกับองค์ประกอบที่อยู่ข้างเคียง
นักเขียนโปรแกรม Lisp ที่มีประสบการณ์ได้วิพากษ์วิจารณ์แนวทางนี้อย่างเฉพาะเจาะจง ชุมชนชี้ให้เห็นว่าเครื่องมือที่มีอยู่และการปรับปรุงประสิทธิภาพที่สั่งสมมาหลายทศวรรษได้ถูกสร้างขึ้นรอบโมเดลการแยกวิเคราะห์แบบเส้นตรง ทำให้ส่วนขยายเหล่านี้ไม่สามารถนำไปใช้งานจริงได้
คำถามเรื่องความสามารถในการอ่าน
บางทีแง่มุมที่ก่อให้เกิดความขัดแย้งมากที่สุดคือไวยากรณ์ที่เสนอมานั้นจริงๆ แล้วปรับปรุงความสามารถในการอ่านหรือไม่ ข้อกำหนดนี้เปลี่ยนนิพจน์ง่ายๆ เช่น (eq (mul (a a)) (pow (a 2))) ให้กลายเป็นเลย์เอาต์ 2 มิติที่ซับซ้อนซึ่งขยายหลายบรรทัดพร้อมสัญลักษณ์ดอกจันที่ทำหน้าที่เป็นเครื่องหมายบริเวณ transposed
สมาชิกชุมชนได้เสนอทางเลือกที่ง่ายกว่ามากสำหรับการปรับปรุงความสามารถในการอ่าน S-expression บางคนเสนอการเยื้องแบบต้นไม้พื้นฐานหรือแม้แต่สัญลักษณ์ทางคณิตศาสตร์เช่น x*x = x^2 สำหรับตัวอย่างที่ให้มา ทางเลือกเหล่านี้รักษาความเรียบง่ายที่สำคัญของ S-expressions ในขณะที่แก้ไขข้อกังวลเรื่องความสามารถในการอ่าน
ทางเลือกในการแก้ปัญหาความสามารถในการอ่านที่แนะนำโดยชุมชน
- Tree notation: โครงสร้างแบบเยื้องง่ายๆ ที่แสดงลำดับชั้น
- Mathematical notation:
x*x = x^2แทนที่จะเป็น(eq (mul (a a)) (pow (a 2))) - Wisp-style: ไวยากรณ์ที่ใช้การเยื้องโดยไม่มีวงเล็บ
- Clojure extensions: เวกเตอร์
[], แฮชแมป{}, เซต{} - Sweet-expressions: แนวทางแบบผสมผสานที่เอาวงเล็บออกแบบเลือกสรร
โซลูชันที่มีอยู่แล้วพร้อมใช้งาน
การสนทนาเผยให้เห็นว่าฟังก์ชันการทำงานที่คล้ายกันมีอยู่แล้วในรูปแบบที่ใช้งานได้จริงมากกว่า ส่วนขยายไวยากรณ์ 2 มิติของ Racket ให้การเขียนโปรแกรมแบบตารางสำหรับกรณีการใช้งานเฉพาะ ในขณะที่ Clojure ได้ขยาย S-expressions ด้วย vectors, hash maps และ sets ได้สำเร็จในขณะที่ยังคงความเรียบง่ายในการแยกวิเคราะห์
สมาชิกชุมชนหลายคนสังเกตว่าความพยายามต่างๆ ในการปรับปรุง S-expressions ได้ถูกลองมาหลายปีแล้ว แต่นักพัฒนายังคงกลับไปใช้รูปแบบเดิมเนื่องจากความสมดุลที่เหมาะสมระหว่างความเรียบง่ายและพลัง
คำตัดสินของชุมชน
แม้ว่าบางคนจะพบว่าแนวทางการทดลองนี้น่าสนใจจากมุมมองทางวิชาการ แต่ฉันทามติโดยรวมคือส่วนขยายที่เสนอมานี้สร้างปัญหามากกว่าที่จะแก้ไข ความซับซ้อนที่เกิดจากการแยกวิเคราะห์ 2 มิติ การหลุดออกจากแบบแผนที่ตั้งไว้ และการปรับปรุงความสามารถในการอ่านที่น่าสงสัย ทำให้คนส่วนใหญ่ปฏิเสธข้อเสนอนี้
การถกเถียงนี้เน้นย้ำถึงความแข็งแกร่งที่ยั่งยืนของ S-expressions แบบดั้งเดิมและความยากลำบากในการปรับปรุงรูปแบบที่ได้พิสูจน์ตัวเองแล้วผ่านการใช้งานจริงมาหลายทศวรรษ ในตอนนี้ดูเหมือนว่าชุมชนนักเขียนโปรแกรมจะยึดติดกับแนวทางที่ได้รับการทดสอบและเชื่อถือได้สำหรับ symbolic expressions
อ้างอิง: S-expr