Mặc dù có các khung được tạo riêng cho mục đích tạo ngôn ngữ lập trình (bao gồm ngữ nghĩa, hệ thống loại, đánh giá, cũng như kiểm tra các thuộc tính về chúng), sự lựa chọn tốt nhất phụ thuộc vào trường hợp cụ thể và nhu cầu cụ thể của bạn.
Như đã nói, có nhiều lựa chọn thay thế (có lẽ không quá khác biệt) mà bạn có thể thực hiện (bao gồm cả những lựa chọn bạn đã đề cập):
- sử dụng một ngôn ngữ / khung cụ thể được thiết kế để tạo và tạo mẫu ngôn ngữ mới: ví dụ: Redex [1], một ngôn ngữ dành riêng cho miền được nhúng trong Vợt để chỉ định và kiểm tra ngữ nghĩa (hoạt động) của các ngôn ngữ lập trình, đưa ra định nghĩa về ngôn ngữ lập trình ngôn ngữ, cung cấp khả năng xử lý dễ dàng các tác vụ như sắp chữ (trong latex), kiểm tra dấu vết giảm, kiểm tra đơn vị và kiểm tra ngẫu nhiên (ví dụ: để kiểm tra gõ)
- sử dụng các ngôn ngữ mô hình hóa chung cung cấp việc xác định và thực hiện các phân tích nhất định một cách dễ dàng, miễn là chúng có thể nắm bắt được ngôn ngữ cụ thể trong phạm vi cần thiết; Alloy [2] là một ví dụ về cách tiếp cận như vậy: mặc dù khá chung chung và linh hoạt, các ngôn ngữ có thể được mô hình hóa thành quan hệ giữa các quốc gia, trong khi hỗ trợ kiểm tra mô hình (ví dụ đánh giá trong ngôn ngữ đó) được cung cấp miễn phí sau khi ngữ nghĩa được thể hiện bằng một mô hình quan hệ (ví dụ: một số ý tưởng để mô hình hóa ngữ nghĩa của ngôn ngữ có thể được tìm thấy trong [3])
- nhúng ngôn ngữ để kiểm tra các thuộc tính của nó bằng cách sử dụng một định lý định lý; một ví dụ sẽ xác định ngôn ngữ cũng như ngữ nghĩa của nó bằng cách nhúng nó vào một hệ thống chứng minh như Coq [4] (chi tiết hơn về phương pháp này, cũng như thảo luận và chứng minh về sự khác biệt giữa nhúng sâu và nông trong Coq được đưa ra trong [ 5])
- sử dụng Ott (như đã đề cập, với tinh thần tương tự như Redex, nhưng cung cấp một ngôn ngữ định nghĩa mới thay vì được nhúng); Ott cho phép bạn xác định ngôn ngữ lập trình theo một ký hiệu thuận tiện và tạo ra các kiểu sắp xếp và định nghĩa trong một hệ thống chứng minh (thường là nhúng sâu), trong đó hầu hết việc kiểm tra (tức là bằng chứng) cần được thực hiện thủ công
- phát triển ngôn ngữ và ngữ nghĩa của nó, cũng như kiểm tra thích hợp (ví dụ như kiểm tra) "từ đầu" bằng ngôn ngữ lập trình đa năng và dịch sang các hệ thống khác nếu cần, để kiểm tra mục đích (một số ngôn ngữ, như Leon [6], bao gồm các trình xác minh tích hợp, cho phép tự động chứng minh các thuộc tính nhất định và làm cho cách tiếp cận này tương tự như nhúng trong một hệ thống chứng minh)
Lưu ý rằng có sự đánh đổi giữa việc sử dụng khung / công cụ dễ dàng như thế nào (ví dụ dễ như đưa ra định nghĩa trên giấy hoặc trong latex) và mức độ mạnh mẽ của các cơ chế kiểm tra các thuộc tính về ngôn ngữ (ví dụ: nhúng ngôn ngữ trong một định lý định lý có thể cho phép kiểm tra các thuộc tính rất phức tạp).
[1] Casey Klein, John Clements, Christos Dimoulas, Carl Eastlund, Matthias Felleisen, Matthew Flatt, Jay A. McCarthy, Jon Rafkind, Sam Tobin-Hochstadt và Robert Bruce Findler. Chạy nghiên cứu của bạn: Về hiệu quả của cơ giới hóa nhẹ. POPL, 2012.
[2] Daniel Jackson. Alloy: một ký hiệu mô hình đối tượng nhẹ. ĐKDV, 2002.
[3] Greg Dennis, Felix Chang, Daniel Jackson. Xác minh mô-đun mã với SAT. ISSTA, 2006
[4] Coq hệ thống quản lý bằng chứng chính thức
[5] Lý luận chính thức về các chương trình. Adam Chlipala, 2016
[6] Leon hệ thống tự động để xác minh, sửa chữa và tổng hợp các chương trình Scala chức năng