2013-04-19 50 views
21

Tôi đang tạo ngữ pháp đầu tiên với ANTLR và ANTLRWorks 2. Tôi hầu như đã hoàn thành ngữ pháp (nó nhận ra mã được viết bằng ngôn ngữ được mô tả và xây dựng các cây phân tích chính xác), nhưng tôi chưa bắt đầu bất cứ điều gì ngoài đó. Điều gì khiến tôi lo ngại là mỗi lần xuất hiện đầu tiên của một mã thông báo trong quy tắc phân tích cú pháp được gạch chân bằng một vệt màu vàng có nghĩa là "Định nghĩa mã thông báo ngụ ý trong quy tắc phân tích cú pháp"."Định nghĩa mã thông báo ngụ ý trong quy tắc phân tích cú pháp" có phải là điều đáng lo ngại không?

Ví dụ, trong quy tắc này, các 'var' có mà squiggle:

variableDeclaration: 'var' IDENTIFIER ('=' expression)?; 

Làm thế nào nó trông giống hệt:

enter image description here

Điều kỳ lạ là ANTLR bản thân dường như không nhớ những quy tắc này (khi thực hiện kiểm tra rig test, tôi không thể thấy bất kỳ cảnh báo nào trong đầu ra của trình phân tích cú pháp, chỉ cần một cái gì đó về phiên bản Java không chính xác đang được cài đặt trên máy của tôi), vì vậy nó chỉ là ANTLRWorks phàn nàn.

Có điều gì đó phải lo lắng hoặc tôi có nên bỏ qua những cảnh báo này không? Tôi có nên khai báo tất cả các mã thông báo một cách rõ ràng trong các quy tắc lexer không? Hầu hết các exaples trong kinh thánh chính thức The Defintive ANTLR Reference dường như được thực hiện chính xác cách tôi viết mã.

Trả lời

14

Tôi khuyên bạn nên sửa tất cả các trường hợp cảnh báo này trong mã có tầm quan trọng bất kỳ.

cảnh báo này đã được tạo ra (bởi tôi thực sự) để cảnh báo bạn về những tình huống như sau:

shiftExpr : ID (('<<' | '>>') ID)?; 

Kể từ ANTLR 4 khuyến khích mã hành động được ghi trong các tập tin riêng biệt trong ngôn ngữ mục tiêu thay vì nhúng chúng trực tiếp trong ngữ pháp, điều quan trọng là có thể phân biệt giữa <<>>. Nếu mã thông báo không được tạo rõ ràng cho các toán tử này, chúng sẽ được gán các kiểu tùy ý và không có hằng số được đặt tên nào sẽ có sẵn để tham chiếu chúng.

Cảnh báo này cũng giúp tránh được những tình huống có vấn đề sau:

  • Một nguyên tắc phân tích cú pháp có chứa một tham chiếu thẻ sai chính tả. Không có cảnh báo, điều này có thể dẫn đến việc tạo ra một mã thông báo bổ sung im lặng mà không bao giờ có thể khớp với nhau.
  • Một nguyên tắc phân tích cú pháp chứa một tham chiếu thẻ không chủ ý, chẳng hạn như sau:

    number : zero | INTEGER; 
    zero : '0'; // <-- this implicit definition causes 0 to get its own token 
    
+0

Ok, cảm ơn bạn, tôi sẽ xem xét việc này.Đối với việc tách mã hành động, có phải cái gì đó nằm ngoài "ngữ pháp kết hợp -> AST -> ngữ pháp cây với mã hành động" không? Tôi chỉ có cuốn sách cho v3, vì vậy nếu nó là một cái gì đó mới, là có bất kỳ bài báo trực tuyến giải thích nó? Tài liệu trực tuyến trên antlr.org dường như thiếu thông tin về sự khác biệt giữa v3 và v4. –

+0

ANTLR 4 không còn bao gồm đầu ra = AST hoặc ngữ pháp cây. Thay vào đó, nó sử dụng các cây phân tích cú pháp với người nghe và/hoặc các giao diện khách truy cập được tạo tự động từ ngữ pháp phân tích cú pháp. –

+0

Tôi nhận thấy rằng ANTLRWorks2 cũng ném cùng một thông báo này khi tôi vô tình sử dụng một mã thông báo được đánh dấu là một đoạn trong quy tắc phân tích cú pháp. Đây có phải là dự định hay nó sẽ hiển thị một lỗi khác? –

0

Nếu bạn đang viết ngữ pháp lexer mà sẽ không được sử dụng trên nhiều ngữ pháp phân tích cú pháp, bạn có thể bỏ qua cảnh báo này được hiển thị bởi ANTLRWorks2.

+0

Tôi đang viết một ngữ pháp kết hợp (và tôi thích nó, tốt hơn nhiều so LEX + YACC), nhưng tôi muốn các ngữ pháp để tạo ra một AST, mà sẽ được tiêu thụ bởi ít nhất hai cây grammars. Điều đó có tính không? Ngoài ra, tại sao downvote? –

+6

Tôi không đồng ý với câu trả lời này vì cảnh báo này có thể cảnh báo các nhà phát triển về các vấn đề ngữ pháp ngay cả khi các mã thông báo chỉ được sử dụng trong một ngữ pháp. Tôi đã đưa ra một số ví dụ trong câu trả lời của tôi. –