Có vẻ như trong các cuộc chiến thần thánh ngôn ngữ, mọi người liên tục chê bai bất kỳ tính năng nào họ không thấy đặc biệt hữu ích là "chỉ là đường cú pháp". Ranh giới giữa "tính năng thực" và "đường cú pháp" có xu hướng bị mờ trong các cuộc tranh luận này. Bạn tin điều gì là một định nghĩa hợp lý và rõ ràng về đường cú pháp để tránh nó được định nghĩa là bất kỳ tính năng nào mà người nói / người viết không thấy hữu ích?
Câu trả lời:
Làm thế nào về điều này: "đường cú pháp là một tốc ký tiện lợi cho một số chức năng không giới thiệu bất kỳ lớp trừu tượng có ý nghĩa."
Hãy a->b, mà, như bạn chỉ ra, là tương đương với (*a).b. Liệu ký hiệu này có cho phép bạn xem xét mã theo bất kỳ cách hữu ích nào khác không? Không, vì vậy đó là cú pháp đường.
Bây giờ hãy xem xét a[i] == *(a + i). Hãy suy nghĩ về bất kỳ chương trình C nào sử dụng mảng theo bất kỳ cách thực chất nào. Bạn có thể tưởng tượng cố gắng để hiểu nó mà không cần []ký hiệu? Với mảng đa chiều? Nó có ý nghĩa để xem xét các mảng như là toàn bộ đơn vị, không phải là một tham chiếu đến sự bắt đầu của một khối bộ nhớ liền kề. Mặc dù sẽ giúp biết các mảng hoạt động như thế nào trong C nếu bạn dự định làm những việc phức tạp với chúng, nhưng sẽ không có ích khi luôn phải nghĩ "Tôi cần lưu trữ hai bit của bộ nhớ 2 * i bên phải vị trí bộ nhớ được tham chiếu bởi a. " Toàn bộ điểm của một mảng là khả năng trừu tượng hóa quá trình lưu trữ một chuỗi như là một đơn vị kết hợp. Các []ký hiệu tạo điều kiện cho sự trừu tượng này. Nó không phải là cú pháp đường.
Điều này không có nghĩa là đường cú pháp luôn là điều xấu. Giống như nhiều sự ám chỉ, nó đã trở thành một biểu tượng và đọ sức với "các tính năng thực sự". Nhưng LISP và Scheme, chẳng hạn, sẽ không thể đọc được nếu không dùng tốc letký (và những thứ khác).
Toán tử ternary <pred> ? <cnsq> : <alt>, là một ví dụ khác. Đường cú pháp có thể giúp tổ chức các chương trình và loại bỏ mã dự phòng, có thể tiết kiệm trong bảo trì xuống dòng. Đường cú pháp đôi khi có thể được ưu tiên hơn so với "tính năng thực" nếu nó giúp loại bỏ các rào cản cú pháp đối với lập trình.
Để trích dẫn R ^ 5RS , "Ngôn ngữ lập trình nên được thiết kế không phải bằng cách chồng chất lên trên tính năng, mà bằng cách loại bỏ các điểm yếu và hạn chế khiến các tính năng bổ sung xuất hiện cần thiết." IMHO, cú pháp có thể đủ điều kiện là một điểm yếu và hạn chế và do đó, để cho các lập trình viên thoát khỏi cú pháp có thể làm tăng tính biểu cảm của ngôn ngữ.
IMHO Tôi không nghĩ bạn có thể có định nghĩa về đường cú pháp, bởi vì cụm từ này là BS và có khả năng được sử dụng bởi những người nói về "lập trình viên thực" bằng cách sử dụng "công cụ thực" trên "hệ điều hành thực"
BS của nó bởi vì ý tưởng về "các tính năng thực" hoặc "đường cú pháp" giống như ngụy biện Không có người Scotland thực sự . Trong đó các cụm từ là "ad hoc cố gắng giữ lại một khẳng định không hợp lý". Sự khẳng định ở đây là một tính năng ở đây là tầm thường bởi vì bạn có thể sử dụng "tính năng thực" thay thế.
BS của nó vì một số người cho rằng nên tránh sử dụng đường vì bạn có thể viết một lỗi nhưng bạn nên bám vào nó vì khó viết lỗi hơn. Không phải là tuyệt vời. Cùng một cụm từ dẫn đến kết luận hoàn toàn ngược lại bằng cách sử dụng cùng một logic.
BS của nó bởi vì không ai trích dẫn các nghiên cứu khả năng sử dụng hoặc nghiên cứu khiếm khuyết, để sao lưu khả năng đọc hoặc khả năng duy trì của họ hoặc có khả năng khiếm khuyết.
BS của nó vì mọi người thường sai hoặc trở nên sai về sự tương đương. Ví dụ câu hỏi này khẳng định rằng chuỗi C # là đường cho một mảng char. Họ không .
Tuy nhiên nếu bạn muốn nói hai điều là đường nếu chúng tương đương về mặt ngữ nghĩa và điều đó giúp đi trước và xác định nó theo bất cứ cách nào bạn muốn.
Nếu bạn muốn loại bỏ một ai đó, bạn cũng có thể sử dụng cụm từ này.
Đây là một định nghĩa rất nghiêm ngặt cho một khái niệm liên quan: tính biểu cảm , của
Matthias Felleisen:
Về sức mạnh biểu cảm của ngôn ngữ lập trình [Postcript là hình thức miễn phí duy nhất tôi có thể tìm thấy.]
Cũng xem mục này trên ngôn ngữ Java và các bao đóng .
Thực tế, một cái gì đó là đường cú pháp nếu nó có thể được thay đổi thành một hình thức mà không cần cú pháp bằng cách chỉ thực hiện các thay đổi cục bộ. Ví dụ, nếu không có dạng cú pháp, bạn sẽ cần thay đổi một số vị trí mã khác nhau hoặc di chuyển các đoạn sang các vị trí khác, thì đó không phải là đường.
Điều đó nói rằng, cú pháp đường là tốt khi được sử dụng một cách thích hợp. Tôi nghĩ rằng bất kỳ lập trình viên Scheme nào cũng muốn có một lethình thức đặc biệt hơn là phải tạo một hàm ẩn danh mới và sau đó áp dụng nó, điều này sẽ làm điều tương tự. Mục đích là để làm cho mã rõ ràng hơn.
Tôi nghĩ thuật ngữ cú pháp chỉ ra một cú pháp thay thế để diễn tả cùng một ngữ nghĩa cơ bản.
Lấy ví dụ một ngôn ngữ lập trình A có một hoạt động sumcó thể thêm một danh sách các số nguyên có độ dài tùy ý. Trong ngôn ngữ này, chúng ta có thể viết các biểu thức
sum []
sum [3, 4, 5, 1]
sum [2, 7]
có kết quả lần lượt là 0, 13 và 9.
Bây giờ, giả sử rằng chúng tôi nhận ra rằng 90% số lần chúng tôi sử dụng sumvới hai đối số và do đó chúng tôi giới thiệu, để thuận tiện, ký hiệu mới
2 + 7
mà chỉ là cú pháp đường cho sum [2, 7].
Bây giờ hãy sử dụng ngôn ngữ thứ hai B không có thao tác bổ sung nào. Chúng tôi có thể có các toán tử như <, =cho phép chúng tôi so sánh các số, nhưng không có cách nào để thêm số. Trong phiên bản 2 của ngôn ngữ B, chúng tôi giới thiệu một hoạt động bổ sung mới với cú pháp
2 + 7
trong đó thêm số như bình thường.
Trong ngữ cảnh của ngôn ngữ A, +ký hiệu là đường cú pháp (nó là một ký hiệu thay thế, đơn giản hóa và đặc biệt có thể được sử dụng thay cho sum [...]ký hiệu). Tương tự, như đã được chỉ ra trong câu trả lời của Hoa Long Tâm, trong C, ký hiệu p->fieldlà đường cú pháp cho (*p).field.
Trong ngữ cảnh của ngôn ngữ B, +ký hiệu không phải là cú pháp đường (nó là cú pháp hợp lệ duy nhất được sử dụng cho phép toán tổng). Tương tự, nếu C chỉ có thể truy cập các thành viên cấu trúc thông qua các con trỏ và nếu không có ký hiệu (*p).fieldthì ký hiệu p->fieldsẽ không phải là đường cú pháp.
Theo tôi, có một số hiểu lầm về đường cú pháp có thể bắt nguồn từ một sự nhầm lẫn liên quan đến ngữ nghĩa ngôn ngữ lập trình. Lý do diễn ra như thế này:
Dòng lý luận trên dẫn đến những khẳng định chung chung như "đường cú pháp không thể được định nghĩa đúng", đó là "vấn đề của hương vị", hay "tất cả các tính năng ngôn ngữ lập trình, xét cho cùng, chỉ là đường cú pháp".
Tôi nghĩ vấn đề chính trong lập luận trên là ngữ nghĩa không chỉ là về những gì có thể được tính toán bởi một chương trình, mà còn về cách nó được tính toán , tức là những cấu trúc nguyên thủy nào được sử dụng và cách chúng được kết hợp.
Vì vậy, ví dụ, các đối tượng không phải là cú pháp cú pháp cho các cấu hình bit và biến đổi bit cơ bản, chúng là một cấu trúc cho phép mô hình hóa dữ liệu và hoạt động và để mô tả các tính toán. Tính toán với các đối tượng, phương thức, lệnh gọi phương thức, không giống như tính toán với byte, thanh ghi bộ xử lý, địa chỉ bộ nhớ (ngay cả khi hai phép tính có cùng kết quả và ngay cả khi tính toán thứ hai được sử dụng để thực hiện lần đầu tiên).
Tôi đã thực hiện mô tả này một chút dài nhưng tôi nghĩ rằng đó là một khía cạnh quan trọng mà tôi chưa thấy giải quyết trong các câu trả lời khác.
Điểm mấu chốt: đường cú pháp là một cú pháp thay thế (có thể thuận tiện hơn) cho một cấu trúc đã có trong ngôn ngữ và đã có một cú pháp và ngữ nghĩa được xác định rõ. Cú pháp mới (đường cú pháp) khác với cú pháp hiện có nhưng có cùng ngữ nghĩa . Nếu bạn giới thiệu một cấu trúc mới trong một ngôn ngữ và cú pháp mới cho nó, thì bạn không có cú pháp cú pháp.
đường cú pháp là một tính năng không tự mở rộng biểu cảm ngôn ngữ, do đó là dư thừa và đôi khi là lạm dụng ký hiệu, nhưng cả hai đơn giản hóa cuộc sống của nhà văn và cung cấp cho người đọc cái nhìn sâu sắc hơn.
Để trả lời câu hỏi của riêng tôi, một tính năng là đường cú pháp nếu và chỉ khi nó được đưa vào chủ yếu để tăng tính thẩm mỹ và khả năng đọc và có thể được dịch một cách tầm thường theo kiểu một-một thành phiên bản khử đường. .
Bất kỳ tính năng nào chỉ có thể được khử đường với một số lượng đáng kể kỷ luật lập trình viên không phải là cú pháp. Là một tập hợp con của điều này, bất kỳ tính năng nào làm tăng tính an toàn của loại không phải là đường cú pháp, vì việc thực thi thủ công an toàn loại thông qua kỷ luật lập trình viên là rất không tầm thường. Ví dụ, hệ thống đối tượng của C ++ không chỉ là đường cú pháp trên đỉnh đa hình con trỏ C.
Bất kỳ tính năng nào sẽ yêu cầu sao chép mã quan trọng hoặc thiết kế lại chính nếu bị loại bỏ không phải là cú pháp, vì cả hai đều không phải là một cam kết tầm thường. Ví dụ, các mẫu không chỉ là đường cú pháp bởi vì để có được chức năng tương đương mà không có chúng sẽ đòi hỏi hàng tấn bản sao và sửa đổi.
Ví dụ về những thứ là cú pháp đường:
a[i] thay vì *(a + i)
a -> b thay vì (*a).b
foreach cú pháp thay vì gõ thủ công cú pháp lặp.
Tất cả quá tải toán tử là đường cú pháp tinh khiết.
Điều này nghe có vẻ như một định nghĩa công bằng và hợp lý rõ ràng?
"Đường cú pháp" không phải là một thuật ngữ được định nghĩa chặt chẽ. Tùy thuộc vào người bạn hỏi, rất có thể bạn sẽ nhận được một trong các loại định nghĩa sau:
Tôi không chắc chắn về các lĩnh vực của khoa học máy tính, nhưng với lĩnh vực logic, có các khái niệm về tính bảo thủ và khả năng loại bỏ các định nghĩa [ 1 ] dường như nằm trong cùng một hướng.
Áp dụng sự tương ứng của Curry-Howard, người ta có thể đưa ra một khái niệm song song liên quan đến đường cú pháp cú pháp.