Các ngôn ngữ hiện đại vẫn sử dụng trình tạo phân tích cú pháp?

Tôi đã nghiên cứu về bộ trình biên dịch gcc trên wikipedia ở đây , khi điều này xuất hiện:

GCC bắt đầu sử dụng các trình phân tích cú pháp LALR được tạo bằng Bison, nhưng dần dần chuyển sang các trình phân tích cú pháp đệ quy gốc viết tay; cho C ++ năm 2004 và cho C và Objective-C năm 2006. Hiện tại tất cả các giao diện người dùng đều sử dụng trình phân tích cú pháp đệ quy gốc viết tay

Vì vậy, bằng câu cuối cùng đó, (và nhiều như tôi tin tưởng wikipedia) tôi chắc chắn có thể nói rằng "C (gcc), C ++ (g ++), Objective-C, Objective-C ++, Fortran (gfortran), Java (gcj), Ada (GNAT), Go (gccgo), Pascal (gpc), ... Mercury, Modula-2, Modula-3, PL / I, D (gdc) và VHDL (ghdl) "đều là những mặt trước không có sử dụng trình tạo phân tích cú pháp lâu hơn. Đó là, tất cả đều sử dụng trình phân tích cú pháp viết tay.

Câu hỏi của tôi là, thực tế này có mặt khắp nơi? Cụ thể, tôi đang tìm câu trả lời chính xác cho "việc triển khai chuẩn / chính thức của x có trình phân tích cú pháp viết tay" cho x trong [Python, Swift, Ruby, Java, Scala, ML, Haskell] không? (Trên thực tế, thông tin về bất kỳ ngôn ngữ nào khác cũng được chào đón ở đây.) Tôi chắc chắn rằng tôi có thể tự mình tìm thấy ngôn ngữ này sau khi đào rất nhiều. Nhưng tôi cũng chắc chắn rằng cộng đồng có thể dễ dàng trả lời được. Cảm ơn!

AFAIK, GCC sử dụng các trình phân tích cú pháp viết tay đặc biệt để cải thiện chẩn đoán lỗi cú pháp (nghĩa là đưa ra các thông điệp có ý nghĩa của con người về lỗi cú pháp).

Lý thuyết phân tích cú pháp (và các trình tạo phân tích cú pháp giảm dần từ nó) chủ yếu là về việc nhận ra và phân tích một cụm từ đầu vào chính xác . Nhưng chúng tôi mong đợi từ các trình biên dịch rằng chúng đưa ra một thông báo lỗi có ý nghĩa (và chúng có thể phân tích một cách có ý nghĩa phần còn lại của đầu vào sau lỗi cú pháp), đối với một số đầu vào không chính xác.

Ngoài ra, các ngôn ngữ cũ - như C11 hoặc C ++ 11- (đã cũ về mặt khái niệm, ngay cả khi bản sửa đổi mới nhất của chúng chỉ mới ba tuổi) hoàn toàn không có ngữ cảnh. Đối phó với sự nhạy cảm ngữ cảnh đó trong ngữ pháp cho các trình tạo phân tích cú pháp (ví dụ như bò rừng hoặc thậm chí menhir ) là rất khó khăn.

Trình tạo phân tích cú pháp và công cụ phân tích cú pháp khá chung chung. Ưu điểm của tính tổng quát là việc xây dựng một trình phân tích cú pháp chính xác một cách nhanh chóng và làm cho nó hoạt động dễ dàng, trong sơ đồ tổng thể của mọi thứ.

Công cụ phân tích cú pháp tự chịu đựng trên mặt trận hiệu suất vì tính tổng quát của nó. Bất kỳ mã viết tay nào cũng sẽ luôn nhanh hơn đáng kể so với các công cụ phân tích cú pháp điều khiển bảng.

Khu vực thứ hai mà các trình tạo / trình phân tích cú pháp gặp khó khăn là tất cả các ngôn ngữ lập trình thực đều nhạy cảm với ngữ cảnh, thường theo những cách khá tinh tế. Các ngôn ngữ LR không có ngữ cảnh, có nghĩa là có nhiều sự tinh tế về định vị và môi trường không thể truyền đạt đúng trong cú pháp. Các ngữ pháp được quy cho cố gắng giải quyết các quy tắc ngôn ngữ cơ bản như "khai báo trước khi sử dụng", v.v. Việc kết nối độ nhạy ngữ cảnh này vào mã viết tay là điều dễ dàng.