Sự khác biệt giữa cú pháp Syntax và đường Syntactic Sugar

Lý lịch

Trang Wikipedia về Syntactic Sugar tuyên bố:

Trong khoa học máy tính, cú pháp đường là cú pháp trong một ngôn ngữ lập trình được thiết kế để làm cho mọi thứ dễ đọc hoặc diễn đạt hơn. Nó làm cho ngôn ngữ "ngọt ngào" hơn cho con người sử dụng: mọi thứ có thể được thể hiện rõ ràng hơn, chính xác hơn hoặc theo một phong cách khác mà một số người có thể thích.

Tôi thực sự không hiểu sự khác biệt giữa Syntactic Sugar và Syntax.

Tôi đánh giá cao điểm mà phiên bản có đường có thể rõ ràng hơn, súc tích hơn, có thể làm sôi một số nồi hơi. Nhưng tôi cảm thấy ở một mức độ nào đó, tất cả các cú pháp về cơ bản đang làm điều đó để hình thành một sự trừu tượng hóa về những gì mã được biên dịch xuống.

Từ cùng một trang Wikipedia:

Các bộ xử lý ngôn ngữ, bao gồm trình biên dịch, máy phân tích tĩnh và tương tự, thường mở rộng các cấu trúc có đường thành các cấu trúc cơ bản hơn trước khi xử lý, một quá trình đôi khi được gọi là "giải mã".

Như một bài tập suy nghĩ, nếu tôi lấy "thường" trong câu lệnh này có nghĩa là "luôn luôn": Nếu sự khác biệt chỉ là liệu trình biên dịch có "giải mã" cú pháp trước khi chuyển sang giai đoạn tiếp theo hay không, làm thế nào một lập trình viên không biết các bộ phận bên trong của trình biên dịch có biết (hoặc quan tâm) Sugar'd Syntax hay không?

Một câu hỏi rất liên quan trên trang web này "Định nghĩa khắt khe về đường cú pháp?" có một câu trả lời bắt đầu:

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"

Điều này có thể cho tôi thấy rằng có lẽ không có sự khác biệt lớn đối với người viết mã sử dụng ngôn ngữ? Có lẽ sự khác biệt chỉ cảm nhận được đối với người viết trình biên dịch? Mặc dù có thể có những trường hợp hữu ích cho người viết mã sử dụng ngôn ngữ để biết những gì thuộc về Syntactic Sugar? (Nhưng có lẽ trong thực tế, bất kỳ diễn ngôn nào về chủ đề này đều có xu hướng sử dụng thuật ngữ này như mồi lửa?)

Trọng tâm của câu hỏi

Vì vậy, ... phiên bản ngắn của câu hỏi:

• Có sự khác biệt thực sự giữa Syntax và Syntactic Sugar?
• Nó quan trọng với ai?

Thực phẩm bổ sung cho suy nghĩ

Phần thưởng về mâu thuẫn chủ đề:

Trên trang Wikipedia, một ví dụ được đưa ra:

Ví dụ, trong ngôn ngữ C, a[i]ký hiệu là đường cú pháp cho*(a + i)

Trong khi đó, một câu trả lời khác cho câu hỏi được liên kết ở trên nói về cùng một ví dụ:

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.

Và tóm tắt rằng:

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.

Kết luận ngược lại cho cùng một ví dụ!

Sự khác biệt chính là cú pháp là ngữ pháp được xác định trong một ngôn ngữ để cho phép bạn thể hiện một số chức năng. Ngay khi bạn có thể có được chức năng đó, bất kỳ cú pháp nào khác cho phép bạn làm điều tương tự đều được coi là đường. Điều đó tất nhiên chạy vào các kịch bản kỳ lạ về cái nào trong hai cú pháp là đường, đặc biệt là vì nó không phải lúc nào cũng rõ ràng trước.

Trong thực tế, đường cú pháp chỉ được sử dụng để mô tả cú pháp được thêm vào một ngôn ngữ để tạo điều kiện dễ sử dụng, như tạo lhs + rhsbản đồ infix thành lhs.Add(rhs). Tôi sẽ coi việc lập chỉ mục mảng của C là đường cú pháp.

Nó quan trọng chủ yếu bởi vì các thiết kế thanh lịch có xu hướng hạn chế số lượng trùng lặp. Một số người cần xem (hoặc ít nhất là muốn) đường cú pháp được coi là một dấu hiệu của một thiết kế thất bại.

Cú pháp là những gì bộ xử lý ngôn ngữ sử dụng để hiểu ý nghĩa của cấu trúc ngôn ngữ. Các cấu trúc được coi là đường cú pháp cũng phải được bộ xử lý ngôn ngữ giải thích và do đó là một phần của cú pháp ngôn ngữ.

Điều làm nên sự khác biệt của cú pháp so với phần còn lại của cú pháp ngôn ngữ là có thể loại bỏ đường cú pháp khỏi ngôn ngữ mà không ảnh hưởng đến các chương trình có thể được viết bằng ngôn ngữ.

Để đưa ra một định nghĩa chính thức hơn, tôi sẽ nói

Đường cú pháp là những phần của cú pháp của ngôn ngữ có hiệu ứng được xác định theo các cấu trúc cú pháp khác trong ngôn ngữ.

Điều này không có nghĩa là chê bai đường cú pháp, hoặc các ngôn ngữ có nó, bởi vì việc sử dụng đường cú pháp thường dẫn đến các chương trình mà ý định của họ dễ hiểu hơn.

Các câu trả lời khác chưa đề cập đến một khái niệm chính: cú pháp trừu tượng ; không có nó, thuật ngữ "cú pháp đường" không có nghĩa gì cả.

Cú pháp trừu tượng xác định các yếu tố và cấu trúc của ngôn ngữ và cách kết hợp các cụm từ của ngôn ngữ đó để xây dựng các cụm từ lớn hơn. Cú pháp trừu tượng là độc lập với cú pháp cụ thể. Theo tôi hiểu, thuật ngữ "cú pháp đường" là một cú pháp cụ thể.

Nói chung, khi thiết kế một ngôn ngữ, bạn sẽ muốn tạo cú pháp cụ thể cho từng thuật ngữ cú pháp trừu tượng của mình để mọi người có thể viết mã bằng ngôn ngữ của bạn bằng văn bản thuần túy.

Bây giờ hãy nói rằng bạn tạo một cú pháp cụ thể khó xử cho foo . Người dùng phàn nàn và bạn triển khai một cú pháp cụ thể mới để thể hiện cùng một cú pháp trừu tượng . Kết quả là cú pháp trừu tượng và ngữ nghĩa của bạn không thay đổi, nhưng bây giờ bạn có hai cú pháp cụ thể cho cùng một thuật ngữ cú pháp trừu tượng.

Tôi tin rằng đây là ý nghĩa của mọi người khi họ nói "cú pháp đường" - những thay đổi chỉ ảnh hưởng đến cú pháp cụ thể, nhưng không ảnh hưởng đến cú pháp trừu tượng hoặc ngữ nghĩa.

Và do đó, sự khác biệt giữa "cú pháp đường" và "cú pháp cụ thể" giờ đã rõ ràng. Với tôi. :)

Cách giải thích này cũng giúp giải thích ý nghĩa của Alan Perlis khi ông nói "đường cú pháp gây ung thư dấu chấm phẩy": tất cả đường cú pháp cụ thể trên thế giới không thể sửa được cú pháp trừu tượng yếu và tất cả những nỗ lực bạn bỏ ra khi thêm đường là nỗ lực bạn không chi tiêu để đối phó với vấn đề thực sự - cú pháp trừu tượng.

Tôi cũng nên lưu ý rằng đây chỉ là ý kiến ​​của tôi; Tôi chỉ tin điều đó bởi vì đó là cách giải thích duy nhất tôi có thể nghĩ về điều đó có ý nghĩa với tôi.

Đường cú pháp là một tập hợp con của cú pháp ngôn ngữ. Ý tưởng cơ bản là có nhiều hơn một cách để nói điều tương tự.

Điều gây khó khăn khi nói đoạn nào là cú pháp cú pháp và đoạn nào là "cú pháp thuần túy" là những câu như "thật khó để nói dạng nào xuất hiện trước" hay "thật khó để biết tác giả của ngôn ngữ này" hay "nó là cách nào hơi tùy tiện để quyết định hình thức nào đơn giản hơn ".

Điều gì làm cho nó dễ dàng quyết định phần nào là thuần hoặc có đường để đặt câu hỏi trong khung của trình biên dịch hoặc trình thông dịch cụ thể. Cú pháp thuần túy là thứ mà trình biên dịch chuyển đổi trực tiếp thành mã máy hoặc trình thông dịch đáp ứng trực tiếp. Đường là thứ đầu tiên được chuyển thành một số thứ cú pháp khác trước khi những điều trực tiếp này xảy ra. Tùy thuộc vào việc thực hiện, điều này có thể hoặc có thể không giống với những gì tác giả dự định hoặc thậm chí những gì mà thông số kỹ thuật tuyên bố.

Trong thực tế, đây là cách mà thực tế của vấn đề được quyết định.

Thực sự, trích dẫn đầu tiên của bạn từ Wikipedia đã nói lên tất cả "... làm cho mọi thứ dễ đọc hơn ...", ".... ngọt ngào hơn cho con người sử dụng ....".

Trong văn bản, các dạng rút gọn như "không" hoặc "không" có thể được coi là đường cú pháp.

Thông thường cú pháp đường là một phần của ngôn ngữ có thể được thể hiện bằng phần hiện tại của ngôn ngữ (cú pháp) mà không mất tính tổng quát nhưng có thể làm mất đi sự rõ ràng. Đôi khi các trình biên dịch có bước giải mã rõ ràng làm biến đổi AST được tạo bởi mã nguồn và áp dụng các bước đơn giản để loại bỏ các nút tương ứng với đường.

Ví dụ: Haskell có đường cú pháp cho các đơn nguyên với các quy tắc sau được áp dụng đệ quy

do { f }            ~> f
do { g; h }         ~> g >> do h
do { x <- f; h }    ~> f >>= \x -> do h
do { let x = f; h } ~> let x = f in do h

Ngay bây giờ nó không quan trọng chính xác nó có nghĩa là gì - tuy nhiên bạn có thể thấy rằng cú pháp đặc biệt trên LHS có thể được chuyển đổi thành một cái gì đó cơ bản hơn trên RHS (cụ thể là các ứng dụng chức năng, lambdas và let'). Các bước này cho phép giữ tốt nhất của cả hai thế giới:

1. Cú pháp trên LHS dễ dàng hơn cho lập trình viên (cú pháp đường) thể hiện các ý tưởng hiện có theo cách rõ ràng hơn
2. Tuy nhiên, vì sự hỗ trợ trong trình biên dịch cho các cấu trúc RHS đã tồn tại trong trình biên dịch, nên nó không cần phải coi nó như một cái gì đó đặc biệt bên ngoài trình phân tích cú pháp và giải mã (trừ báo cáo lỗi).

Tương tự như vậy trong C, bạn có thể tưởng tượng quy tắc viết lại desugaring (do quá tải toán tử, v.v. điều đó không đúng với C ++):

f->h ~> (*f).h
f[h] ~> *(f + h)

Bạn có thể tưởng tượng việc viết tất cả các chương trình mà không sử dụng ->hoặc []bằng C sử dụng cấu trúc này ngày hôm nay. Tuy nhiên, sẽ khó hơn cho các lập trình viên sử dụng nó do đó cung cấp cú pháp đường (tôi đoán trong năm 70 nó cũng có thể đơn giản hóa công việc cho trình biên dịch). Có thể ít rõ ràng hơn khi bạn có thể thêm quy tắc viết lại, hoàn toàn hợp lệ, sau đây:

*f ~> f[0] -- * and [] have the same expressiveness 

Là cú pháp đường xấu? Không nhất thiết - có nguy cơ rằng nó sẽ được sử dụng như sùng bái hàng hóa mà không hiểu ý nghĩa sâu sắc hơn. Ví dụ, các hàm sau tương đương trong Haskell, nhưng nhiều người mới bắt đầu sẽ viết biểu mẫu đầu tiên mà không hiểu rằng họ đang lạm dụng đường cú pháp:

f1 = do x <- doSomething
        return x
f2 = doSomething

Ngoài ra, cú pháp đường có thể quá phức tạp ngôn ngữ hoặc quá hẹp để cho phép mã thành ngữ tổng quát. Ngoài ra, điều đó có thể có nghĩa là ngôn ngữ không đủ mạnh để thực hiện một số điều dễ dàng - có thể là do thiết kế (không cung cấp cho các nhà phát triển công cụ sắc bén hoặc ngôn ngữ thích hợp cụ thể mà việc thêm cấu trúc mạnh hơn sẽ làm tổn thương các mục tiêu khác) hoặc do thiếu sót - sau này hình thức đã cho cú pháp đường tên xấu. Nếu ngôn ngữ đủ mạnh để sử dụng các cấu trúc khác mà không cần thêm cú pháp, nó được coi là thanh lịch hơn để sử dụng các cấu trúc đó.

Tôi nghĩ ví dụ rõ ràng nhất sẽ là cú pháp "+ =" trong C.

i = i + 1;

và

 i +=  1;

thực hiện chính xác cùng một thứ và biên dịch thành chính xác cùng một bộ hướng dẫn máy. Hình thức thứ hai lưu một vài ký tự gõ, nhưng, quan trọng hơn làm cho nó rất rõ ràng rằng bạn đang sửa đổi một giá trị dựa trên giá trị hiện tại của nó.

Tôi sẽ trích dẫn toán tử post / prefix "++" làm ví dụ chính tắc nhưng nhận ra rằng điều này còn hơn cả cú pháp cú pháp. Không có cách nào để diễn tả sự khác biệt giữa ++ i và i ++ trong một biểu thức bằng cách sử dụng i = i + 1cú pháp.

Đầu tiên, tôi sẽ giải quyết một số câu trả lời khác bằng một ví dụ cụ thể. Vòng lặp dựa trên phạm vi C ++ 11 (giống như vòng lặp foreach trong các ngôn ngữ khác nhau)

for (auto value : container) {
    do_something_with(value);
}

hoàn toàn tương đương với (tức là phiên bản có đường)

for (auto iterator = begin(container); iterator != end(container); ++iterator) {
    do_something_with(*iterator);
}

Bây giờ, mặc dù không thêm cú pháp trừu tượng hoặc ngữ nghĩa mới vào ngôn ngữ, nhưng nó có tiện ích thực sự.

Phiên bản đầu tiên làm cho ý định (truy cập mọi mục trong một thùng chứa) rõ ràng. Nó cũng nghiêm cấm các hành vi bất thường như sửa đổi container trong quá trình truyền tải hoặc tiến xa hơn iteratortrong thân vòng lặp hoặc nhận các điều kiện vòng lặp sai một cách tinh tế. Điều này tránh các nguồn có thể có lỗi và, khi làm như vậy, sẽ giảm bớt khó khăn trong việc đọc và suy luận về mã.

Ví dụ: lỗi một ký tự trong phiên bản thứ hai:

for (auto iterator = begin(container); iterator <= end(container); ++iterator) {
    do_something_with(*iterator);
}

đưa ra lỗi một quá khứ và hành vi không xác định.

Vì vậy, phiên bản có đường là hữu ích chính xác bởi vì nó hạn chế hơn, và do đó đơn giản hơn để tin tưởng & hiểu.

Thứ hai, cho câu hỏi ban đầu:

Có sự khác biệt thực sự giữa Syntax và Syntactic Sugar?

Không, "cú pháp đường" là cú pháp ngôn ngữ (cụ thể), được coi là "đường" vì nó không mở rộng cú pháp trừu tượng hoặc chức năng cốt lõi của ngôn ngữ. Tôi thích câu trả lời của Matt Fenwick về điều này.

Nó quan trọng với ai?

Nó quan trọng đối với người sử dụng ngôn ngữ, cũng như bất kỳ cú pháp nào khác, và trong đó đường được cung cấp để hỗ trợ (và trong một số ý nghĩa phù hộ) thành ngữ cụ thể.

Cuối cùng, về câu hỏi tiền thưởng

Ký hiệu [] tạo điều kiện cho sự trừu tượng này.

điều này nghe có vẻ giống như định nghĩa của cú pháp cú pháp: nó hỗ trợ (và cung cấp phước lành cho các tác giả ngôn ngữ) bằng cách sử dụng con trỏ làm mảng. Hình p[i]thức không thực sự hạn chế hơn *(p+i), vì vậy sự khác biệt duy nhất là sự truyền đạt rõ ràng về ý định (và mức tăng khả năng đọc nhẹ).

Dù ý nghĩa ban đầu của cụm từ là gì, ngày nay nó chủ yếu là một từ ngữ, hầu như luôn được gọi là đường cú pháp "chỉ" hoặc "chỉ". Nó chỉ là vấn đề đối với các lập trình viên thích làm mọi thứ theo cách không thể đọc được và muốn một cách ngắn gọn để biện minh điều đó cho các đồng nghiệp của họ. Một định nghĩa của những người chủ yếu sử dụng thuật ngữ ngày nay, theo quan điểm của họ, sẽ là một cái gì đó như:

Cú pháp dư thừa với cú pháp được áp dụng rộng rãi hơn khác, để cung cấp một cái nạng cho các lập trình viên không thực sự hiểu ngôn ngữ.

Đó là lý do tại sao bạn nhận được hai kết luận trái ngược cho cùng một yếu tố cú pháp. Ví dụ đầu tiên của bạn về ký hiệu mảng là sử dụng ý nghĩa tích cực ban đầu của thuật ngữ, một cái gì đó tương tự như câu trả lời của Bart. Ví dụ thứ hai của bạn là bảo vệ ký hiệu mảng chống lại trách nhiệm là đường cú pháp theo nghĩa miệt thị. Nói cách khác, nó đang tranh luận cú pháp là một sự trừu tượng hữu ích chứ không phải là một cái nạng.