Có phải đầu ra của một trình phân tích cú pháp phải là một cây hoặc nó cũng có thể là biểu đồ chung?
Hơn nữa, có bất kỳ ngôn ngữ hiện có hoặc một ngôn ngữ hợp lý sử dụng biểu diễn đồ thị chung thay vì cây cho cú pháp của họ không?
Câu trả lời:
Đầu ra của một trình phân tích cú pháp không cần phải là một cây. Thật vậy, khi bạn xem xét những thứ như tham chiếu từ USE của một biến đến DEF định của nó được phủ lên trên cây cú pháp trừu tượng, bạn ngay lập tức có một biểu đồ.
Vấn đề là phân tích cú pháp thường được thiết kế để diễn ra trong một lần duy nhất - điều này quan trọng vì lý do lịch sử, chẳng hạn như thiếu không gian và tốc độ xử lý, nhưng cũng vì lý do đơn giản hơn. Sau đó các giai đoạn tiếp theo trang trí cây phân tích với thông tin bổ sung.
Có những thứ như ngữ pháp đồ thị, mặc dù tôi không biết liệu chúng có được sử dụng để phân tích ngôn ngữ lập trình hay không.
Câu hỏi của OP là một chút lạc hậu đã nêu. Tất nhiên, một thuật toán phân tích cú pháp có thể xuất ra bất cứ thứ gì nó muốn. Câu hỏi là nhiều hơn để hiểu phân tích cú pháp là gì và liệu trình phân tích cú pháp có đưa ra kết quả đáp ứng mục tiêu này hay không. Sau đó, người ta có thể tự hỏi đâu là đại diện thích hợp cho điều đó, ví dụ như một cái cây hoặc một biểu đồ.
Chà, tôi đoán một trình phân tích cú pháp là một thuật toán sẽ cung cấp cho bạn cấu trúc cú pháp của một câu được đưa ra làm đầu vào, theo một định nghĩa chính thức nhất định về cú pháp của ngôn ngữ.
Lưu ý rằng mọi người có thể không đồng ý về những gì cấu thành cú pháp của ngôn ngữ. Một số có thể giới hạn điều đó đối với một xương sống ngôn ngữ chính thức thuần túy, trong khi những người khác có thể đưa ra những cân nhắc về ngữ nghĩa hơn một chút như loại, thể loại, số hoặc những thứ phức tạp hơn (tôi không phân biệt NLP hoặc ngôn ngữ lập trình). Hầu hết các ngôn ngữ đều có các tính năng yêu cầu biểu đồ được thể hiện, nhưng tùy thuộc vào "người triển khai" (vì không có từ nào tốt hơn) để quyết định liệu anh ta có muốn đưa nó vào cú pháp hay không.
Vì vậy, tùy thuộc vào những gì bạn xác định cú pháp sẽ là, bạn có thể phải xuất ra một loại cấu trúc chính thức khác.
Trong trường hợp đơn giản của phân tích cú pháp không ngữ cảnh thuần túy, một cây phân tích cú pháp có thể làm, ngoại trừ vấn đề không rõ ràng được giải quyết bên dưới, hoặc thực tế là bạn có thể muốn sửa đổi nó một chút để có AST (xem bên dưới).
Tuy nhiên, trong các trường hợp phức tạp hơn, bạn có thể cần các cấu trúc khác nhau, thường được biểu thị bằng các liên kết trong cây, do đó dẫn đến cấu trúc biểu đồ. Điều này phụ thuộc rất nhiều vào định nghĩa của bạn về cú pháp ngôn ngữ.
Ngoài ra, cây bạn nên đầu ra là không rõ ràng. Nếu bạn sử dụng trường hợp ngữ pháp liền kề cây (TAG), chúng hoạt động theo cách mà cây cú pháp không giống với cây phái sinh, mặc dù cái trước có thể được dẫn xuất từ cái sau. Mà bạn muốn đầu ra có thể là một câu hỏi có liên quan.
Ngoài ra còn có một vấn đề khác liên quan đến sự mơ hồ. Một câu nhất định, trong khi thuộc về ngôn ngữ của bạn, có thể làm như vậy theo nhiều cách khác nhau, có thể được chỉ định một cấu trúc cú pháp theo nhiều cách khác nhau.
Sau đó, bạn có thể chọn chỉ xuất một trong các cấu trúc này, được chọn ngẫu nhiên hoặc theo một số tiêu chí được xác định rõ (ví dụ như likeyhood). Bạn cũng có thể chọn đầu ra một vài hoặc tất cả chúng. Nếu bạn muốn xuất một số, nó thường được đóng gói trong một cấu trúc duy nhất sẽ chia sẻ những gì chúng có chung. Điều này tiết kiệm không gian và thời gian tính toán, và sự phức tạp có thể là một vấn đề thực sự.
Khi bạn chọn xuất tất cả chúng, bạn không có lựa chọn nào khác ngoài việc chia sẻ, bởi vì có thể có vô số các phân tích cú pháp có thể. Và vô hạn có thể được phản hồi một cách hữu hạn chỉ bằng cách nào đó có một chu kỳ trong biểu đồ. Vì vậy, bạn phải sản xuất một cấu trúc đồ thị nói chung. Nhưng các thuộc tính của cấu trúc biểu đồ này có liên quan đến loại cú pháp chính thức mà bạn đã chọn.
Bây giờ câu hỏi cũng là về Cây Cú pháp Trừu tượng. Tôi đã bỏ qua phần "trừu tượng" vì nó sẽ mang lại sự nhầm lẫn, imho. Thật vậy, câu hỏi đã gây nhầm lẫn trong các phần khác nhau của nó.
Về AST theo quan điểm lịch sử, chúng bắt nguồn từ ngôn ngữ Lisp và các hệ thống thao tác chương trình trong những năm 1960-1970. Ý tưởng là coi các chương trình là các biểu thức lớn, như các công thức toán học, cho cả mục đích thao tác và phân tích các thuộc tính hoặc định nghĩa ngữ nghĩa theo cách chính thức, mà các nhà toán học biết cách làm trên các công thức. Theo công thức, chúng có cấu trúc cây tự nhiên, nhưng có thể được trang trí bằng nhiều thông tin khác nhau biến những cây này thành biểu đồ. Điều này thuận tiện cả chính thức và thực dụng và được tiếp tục sử dụng bởi các trình biên dịch và hệ thống lập trình.
Về cơ bản, AST là một cái cây, theo ngụ ý của tên, nhưng có thể mang thêm thông tin. Phần còn lại nằm trong sự lựa chọn của người thực hiện và trong mắt của kẻ si tình. Nó là một biểu đồ hoặc một cây trang trí? Tuy nhiên, cây AS cơ bản quan trọng, bởi vì đó là giàn giáo bạn xây dựng trên cả lý thuyết và lập trình.
Lưu ý rằng AST khác với cây phân tích cú pháp (cú pháp dựa trên ngữ cảnh) được tạo ra bằng thuật toán phân tích cú pháp như được nghiên cứu trong lý thuyết ngôn ngữ chính thức. Lý do là việc thiết kế cú pháp bị hạn chế bởi công nghệ phân tích cú pháp thời đó, bản thân nó bị hạn chế bởi sức mạnh tính toán thấp có sẵn. Kết quả là các cây cú pháp chỉ là các biến thể bị tra tấn của cái mà người ta sẽ xem xét một cách tự nhiên cấu trúc của chương trình, và xử lý thêm, không phải là một phần của quá trình phân tích cú pháp chính thức cơ bản, phải được thực hiện để có được phiên bản đơn giản hơn và đơn giản hơn có tên AST.
Tuy nhiên, việc biểu diễn các cây trên máy tính, dù trừu tượng hay không, có phần bị hạn chế khi bạn muốn biểu diễn tất cả các cấu trúc của một câu mơ hồ. Đặc biệt, điều này ẩn giấu các vấn đề phức tạp. Bảo tồn sự mơ hồ trong cấu trúc biểu đồ, trong khi dịch từ cây phân tích sang cây AS cũng có thể là một vấn đề. Tuy nhiên, nếu bạn quan tâm đến điều đó, thường có thể định nghĩa cú pháp cụ thể của bạn theo cách mà cây phân tích có thể đóng vai trò là AST. Điều này được cho phép bởi các thuật toán rất chung xử lý sự mơ hồ và sức mạnh của các máy tính hiện tại.
Nếu bạn phân tích cú pháp bằng cách sử dụng phân tích cú pháp GLR (Generalized LR) và nếu phân tích cú pháp của đầu vào không rõ ràng (có nhiều cách có thể để phân tích cú pháp đầu vào), thì kết quả của phân tích cú pháp có thể được coi là một DAG phân tích, thay vì một cây phân tích. DAG phân tích cú pháp mã hóa gọn gàng nhiều phân tích có thể: nhiều cây phân tích có thể.
Tuy nhiên, điểm mấu chốt vẫn là nếu bạn có ngữ pháp không ngữ cảnh và nếu chuỗi đầu vào của bạn có thể phân tích cú pháp rõ ràng (chỉ có một dẫn xuất duy nhất trong ngữ pháp tạo ra chuỗi đầu vào này) và nếu công việc phân tích cú pháp là tạo ra dẫn xuất đó ... sau đó trong các điều kiện này, đầu ra của phân tích cú pháp sẽ luôn luôn là một cây phân tích cú pháp, bởi vì bất kỳ sản phẩm nào của một ngữ pháp không ngữ cảnh vốn có cấu trúc cây.
Tôi đã từng viết một trình thông dịch cho C trong đó "AST" cho toán tử + = (ví dụ) không phải là một cây. Xem xét a[i++] += dnơi a[i++]đang intvà dlà double. Các hoạt động chuyển đổi và tìm nạp ngầm định đã rõ ràng trong cây, vì vậy vấn đề là đặt nơi tìm nạp a[i++]và chuyển đổi thành gấp đôi. Giải pháp của chúng tôi là bỏ cây. Kết quả "ASG" trông như thế này
+=
/ | \
/ | \
/ | \
/ convert \
| | \
| fetch fetch
| / |
index d
/ \
a postinc
|
i
Bản thân tôi đã rất bối rối, cho đến khi tôi nhận ra rằng đó không phải là cây trừu tượng, nó cũng không phải là về một "cây cú pháp" trừu tượng, mà là cú pháp trừu tượng.
Vì vậy, để trả lời câu hỏi của bạn, tôi kết luận rằng một cây cú pháp trừu tượng, cũng như cây cú pháp cụ thể hoặc cây quyết định, hoặc bất kỳ cây nào khác, tốt hơn nên là một cây.
Mặt khác, không có gì nên ngăn bất kỳ ai sử dụng biểu đồ cú pháp trừu tượng hoặc sơ đồ cú pháp trừu tượng hoặc khối cú pháp trừu tượng hoặc đặc tả cú pháp trừu tượng.
Tôi cho rằng một cây cú pháp trừu tượng của "cây cú pháp trừu tượng" sẽ giúp tôi tránh được sự nhầm lẫn.