Một tài liệu đặc tả mới cho S-expressions đã giới thiệu các phần mở rộng gây tranh cãi, thách thức cơ bản các quy ước cú pháp lập trình truyền thống. Thư viện S-expr đề xuất thêm các chuỗi nhiều dòng, comment, và đáng chú ý nhất là các khối chuyển vị cho phép code được viết theo bố cục hai chiều với hướng dọc và ngang.
Tài liệu này, nhắm đến những người mới bắt đầu lập trình, gợi ý rằng những phần mở rộng này có thể cải thiện khả năng đọc code bằng cách giải quyết vấn đề phổ biến của dấu ngoặc đơn lồng nhau trong các ngôn ngữ kiểu Lisp. Tuy nhiên, phản ứng của cộng đồng lập trình đã rất hoài nghi.
So sánh cú pháp chuỗi
| Loại | S-expr truyền thống | Phần mở rộng S-expr |
|---|---|---|
| Chuỗi một dòng | "text" |
"text" |
| Chuỗi nhiều dòng | Không hỗ trợ | ***\ntext\n*** |
| Bình luận | ;comment |
//comment// hoặc ///\ncomment\n/// |
| Khối 2D | Không hỗ trợ | *\nvertical\ntext\n* |
Các Nguyên Tắc S-Expression Truyền Thống Bị Tấn Công
Các phần mở rộng được đề xuất vi phạm những nguyên tắc cốt lõi đã làm cho S-expressions thành công trong nhiều thập kỷ. S-expressions truyền thống bỏ qua hầu hết khoảng trắng và có thể được phân tích cú pháp tuyến tính mà không cần quay lui. Cấu trúc 2D mới phá vỡ cơ bản mô hình này bằng cách yêu cầu parser phải nhảy dọc qua code và đọc đầy đủ các khối nhiều dòng trước khi tiếp tục với các phần tử liền kề.
Các lập trình viên Lisp có kinh nghiệm đã đặc biệt chỉ trích cách tiếp cận này. Cộng đồng chỉ ra rằng các công cụ hiện có và hàng thập kỷ tối ưu hóa đã được xây dựng dựa trên mô hình phân tích tuyến tính, khiến những phần mở rộng này không thực tế cho việc sử dụng thực tế.
Câu Hỏi Về Khả Năng Đọc
Có lẽ khía cạnh gây tranh cãi nhất là liệu cú pháp được đề xuất có thực sự cải thiện khả năng đọc hay không. Đặc tả biến đổi các biểu thức đơn giản như (eq (mul (a a)) (pow (a 2))) thành các bố cục 2D phức tạp trải dài nhiều dòng với các ký hiệu dấu sao đánh dấu các vùng chuyển vị.
Các thành viên cộng đồng đã đề xuất các phương án thay thế đơn giản hơn nhiều để cải thiện khả năng đọc S-expression. Một số đề xuất thụt lề cơ bản kiểu cây hoặc thậm chí ký hiệu toán học như x*x = x^2 cho ví dụ đã cho. Những phương án thay thế này duy trì tính đơn giản cốt yếu của S-expressions trong khi giải quyết các mối quan tâm về khả năng đọc.
Các Giải Pháp Cải Thiện Khả Năng Đọc Được Đề Xuất Bởi Cộng Đồng
- Ký hiệu cây: Cấu trúc thụt lề đơn giản thể hiện phân cấp
- Ký hiệu toán học:
x*x = x^2thay vì(eq (mul (a a)) (pow (a 2))) - Phong cách Wisp: Cú pháp dựa trên thụt lề không có dấu ngoặc đơn
- Phần mở rộng Clojure: Vectors
[], hash maps{}, sets{} - Sweet-expressions: Phương pháp lai ghép với việc loại bỏ dấu ngoặc đơn có chọn lọc
Các Giải Pháp Hiện Có Đã Sẵn Sàng
Cuộc thảo luận tiết lộ rằng chức năng tương tự đã tồn tại dưới các dạng thực tế hơn. Phần mở rộng cú pháp 2D của Racket cung cấp lập trình dựa trên bảng cho các trường hợp sử dụng cụ thể, trong khi Clojure đã thành công mở rộng S-expressions với vector, hash map và set trong khi vẫn duy trì tính đơn giản của phân tích cú pháp.
Một số thành viên cộng đồng lưu ý rằng nhiều nỗ lực cải thiện S-expressions đã được thử qua các năm, nhưng các nhà phát triển liên tục quay trở lại định dạng gốc do sự cân bằng tối ưu giữa tính đơn giản và sức mạnh.
Phán Quyết Của Cộng Đồng
Trong khi một số thấy cách tiếp cận thử nghiệm này thú vị từ góc độ học thuật, sự đồng thuận áp đảo là các phần mở rộng được đề xuất tạo ra nhiều vấn đề hơn là giải quyết. Sự phức tạp được giới thiệu bởi phân tích 2D, sự phá vỡ các quy ước đã được thiết lập, và những cải thiện khả năng đọc đáng ngờ đã khiến hầu hết bác bỏ đề xuất này.
Cuộc tranh luận làm nổi bật sức mạnh bền bỉ của S-expressions truyền thống và khó khăn trong việc cải thiện một định dạng đã chứng minh bản thân qua nhiều thập kỷ sử dụng thực tế. Hiện tại, có vẻ như cộng đồng lập trình sẽ gắn bó với cách tiếp cận đã được thử nghiệm và đúng đắn đối với biểu thức ký hiệu.
Tham khảo: S-expr