Định dạng chuẩn cho cây cú pháp cụ thể và trừu tượng

Question

Tôi có ý tưởng cho một dự án sở thích thực hiện một số phân tích và thao tác mã. Dự án này sẽ yêu cầu cả hai cây cú pháp cụ thể và trừu tượng của một tệp nguồn đã cho. Ngoài ra, các tham chiếu hai chiều giữa hai cây sẽ hữu ích. Tôi muốn tránh việc sao chép một ngữ pháp để xây dựng từ vựng và trình phân tích cú pháp của riêng tôi.

Có định dạng chuẩn để mô tả cây cú pháp cụ thể hoặc trừu tượng không? Có bất kỳ chuỗi công cụ được sử dụng rộng rãi nào hỗ trợ xuất ra các định dạng này không?

Tôi không có một ngôn ngữ lập trình mục tiêu cụ thể nào. Bất kỳ một trong những phổ biến sẽ làm cho một mẫu thử nghiệm, nhưng tôi muốn một trong những tôi cũng biết: Python, C#, Javascript, hoặc C/C + +.

Tôi muốn có khả năng chạy tệp nguồn thông qua công cụ hoặc thư viện và lấy lại cả hai cây. Trong một thế giới lý tưởng, nó sẽ là thực tế để chạy công cụ này trên mã như nó đang được chỉnh sửa bởi một người sử dụng và được khoan dung của các lỗi. Một lần nữa, tôi chỉ đơn giản là cố gắng để phát triển một nguyên mẫu, vì vậy các yêu cầu này là khá lỏng lẻo.

Cảm ơn!

Answer 1

Trong our project chúng tôi đã xác định metamodel AST trong UML và sử dụng ANTLR (Java) để điền mô hình. Chúng tôi cũng duy trì thông tin mã thông báo từ ANTLR sau khi phân tích cú pháp, nhưng chúng tôi chưa cố gắng cập nhật tệp văn bản cơ bản với các sửa đổi được thực hiện trên mô hình.

Điều này có chi phí khủng khiếp (trong cơ sở hạ tầng, chẳng hạn như Eclipse UML2/EMF), nhưng mục tiêu của chúng tôi là sử dụng các công cụ cấp cao cho Phát triển dựa trên mô hình/định hướng (MDD, MDA), vì vậy chúng tôi quyết định sử dụng nó trên mỗi cấp độ.

Tôi nghĩ một trong những sinh viên của chúng tôi đã từng chơi với OpenArchitectureWare và quản lý để nhận các thay đổi từ trình chỉnh sửa dựa trên Eclipse, được tạo lại vào cây cú pháp (không liên quan đến mô hình UML ở trên) một cách tự động, nhưng tôi không biết chi tiết về điều này.

Bạn cũng có thể muốn xem ANTLR's ngữ pháp cây.

Answer 2

Cộng đồng nghiên cứu quyết định trao đổi đồ thị là điều đúng đắn cần làm khi di chuyển thông tin từ một công cụ phân tích chương trình này sang công cụ phân tích chương trình khác. Xem http://www.gupro.de/GXL

Gần đây hơn, OMG đã xác định tiêu chuẩn cho thay đổi cây cú pháp trừu tượng. Xem http://www.omg.org/spec/ASTM/1.0/Beta1/

Sự cố này dường như được giải quyết nhiều lần. Có nửa tá đề xuất "bus công cụ" được thực hiện trong những năm rằng tất cả đã giải quyết được vấn đề đó, không ai vượt qua ngành công nghiệp này. Vấn đề là a) dễ dàng đại diện cho AST bằng cách sử dụng bất kỳ loại ký hiệu có thể lồng nào [ngoặc đơn như LISP, như XML, ...] để mọi người cuộn giải pháp của riêng mình dễ dàng, và b) cho một công cụ để trao đổi một AST với nhau, chúng cả hai đều phải đồng ý về những gì các nút AST có ý nghĩa; nhưng hầu hết các ASTs là vô tình bắt nguồn từ công nghệ ngữ pháp/phân tích cú pháp cụ thể được sử dụng bởi mỗi công cụ, và có hầu như luôn không đồng ý về điều đó giữa các công cụ. Vì vậy, tôi đã thấy rất ít công cụ trao đổi AST một cách có ý nghĩa.

Nếu bạn đang làm một điều thú vị, tôi sẽ gắn bó với một đoạn mã như cây xanh, nơi mỗi nút có định dạng sau: (...) Dễ dàng tạo và dễ dàng đọc.

Tôi làm việc theo số professional tool to manipulate programs. Nếu chúng tôi có in ra AST, chúng tôi làm như trên. Chủ yếu là cá nhân ASTs là quá phức tạp để xem xét trong thực tế, vì vậy chúng tôi hầu như không bao giờ in ra toàn bộ AST, tốt nhất chỉ một nút và một vài trẻ em sâu. Công cụ của chúng tôi không trao đổi AST với bất kỳ ai (xem lý do ở trên :) nhưng chỉ cần xây dựng nó trong bộ nhớ, thực hiện những điều phù hợp với nó vì lý do phân tích hoặc lý do chuyển đổi và sau đó chỉ xóa nó (không cần phải gửi nó ở bất kỳ đâu) hoặc tạo lại văn bản ngôn ngữ gốc từ cây. [Điều sau có nghĩa là bạn cần công cụ chống phân tích cú pháp hoặc "đẹp" ]

Answer 3

Tiêu chuẩn cụ thể là kỳ vọng, trong khi các tiêu chuẩn mục đích chung hơn cũng có thể phù hợp. Ira Baxter đã đề cập đến GXL và RDF cũng có thể được thêm vào, chỉ rằng nó sẽ yêu cầu bản thể luận thích hợp và định hướng nhiều hơn về ngữ nghĩa hơn cú pháp. Vẫn có thể là một tùy chọn để điều tra.

Đối với tiêu chuẩn cụ thể, Ira Baxter đã đề cập ASTM, một số khác, mặc dù nó khá đặt mục tiêu cụ thể của loại ngôn ngữ lập trình (ngôn ngữ logic), là a standard for semantic/conceptual graph, được gọi là ISO‑IEC 24707 2007.

Không phải là tiêu chuẩn, mà là một bài báo về vấn đề đó: Towards Portable Source Code Representations Using XML .

Tôi không biết bất kỳ tiêu chuẩn được sử dụng hiệu quả nào (trong khu vực này, luôn luôn được nấu ở nhà ở mọi nơi), tôi chỉ quan tâm đến chủ đề này.