Làm thế nào để tôi đi về viết một đặc tả ngôn ngữ lập trình?

Tôi thực sự thích thiết kế ngôn ngữ lập trình. Đôi khi tôi nghĩ các dự án ngôn ngữ của tôi và người dùng tiềm năng của họ sẽ được hưởng lợi từ một tài liệu tiêu chuẩn toàn diện. Tôi đã xem xét nhiều tiêu chuẩn ngôn ngữ, từ rất chính thức (C ++) đến khá không chính thức (ECMAScript), nhưng tôi thực sự không thể kiểm soát được cách tôi nên phá vỡ mọi thứ và tổ chức một tài liệu như vậy, mặc dù tôi nghĩ rằng tôi khá giỏi về kỹ thuật viết nói chung.

Tôi có nên viết nó như một bài hướng dẫn dài, hay giống như một bài toán chính thức? Làm cách nào để cập nhật thông tin nếu tôi đang phát triển nó cùng với triển khai tham chiếu? Tôi có nên từ bỏ và coi việc thực hiện và tài liệu là tiêu chuẩn thực tế không? Hơn nữa, có thực sự có lợi ích đáng kể để có một tiêu chuẩn? Có yêu cầu một tiêu chuẩn có nghĩa là ngôn ngữ là phức tạp không cần thiết?

Tôi đã tìm thấy đặc tả ngôn ngữ Java cả chính thức và dễ đọc và tôi nghĩ rằng nó có cấu trúc hợp lý. Một số thông số kỹ thuật của W3C cũng có thể là ví dụ tốt.

Làm công việc chính thức có thể giúp bạn giảm độ phức tạp của ngôn ngữ và xem các trường hợp góc.

Tiêu đề não bộ: mã hóa nguồn, từ vựng, các loại cơ bản, chữ, toán tử, biểu thức, câu lệnh đơn giản, điều kiện, vòng lặp, hàm (định nghĩa và lệnh gọi), khai báo kiểu, mô-đun, đơn vị biên dịch, phạm vi biến, các loại phân giải tên (ví dụ nhập khẩu, phương thức), mô hình bộ nhớ, tác dụng phụ, đánh máy, đồng thời

Đọc nhiều và giữ cho nó đơn giản

Thiết kế một ngôn ngữ mới là khó. Thực sự khó khăn. Nhưng cuối cùng rất thỏa mãn nếu nó trở nên phổ biến và thực sự giải quyết một vấn đề mà mọi người đang gặp phải một cách thanh lịch.

Như tôi đã đề cập trong các bình luận, tôi khuyên bạn nên đọc Ngôn ngữ cụ thể miền của Martin Fowler vì những lý do sau:

1. Ông đi sâu vào thực tế về lý do tại sao bạn nên thiết kế một ngôn ngữ
2. Có các chi tiết về cách thực hiện (trình phân tích cú pháp, phân tích từ vựng, bàn làm việc ngôn ngữ, v.v.)
3. Có các hướng dẫn triển khai chi tiết về cách cú pháp bạn chọn có thể được thực hiện để xử lý các khái niệm như bao đóng, chú thích, danh sách bằng chữ, tiếp nhận động, v.v.

Về cách viết về đặc tả của bạn, hãy nghĩ về khán giả của bạn. Rõ ràng, trước khi đặt ngón tay lên bàn phím để thiết kế ngôn ngữ của bạn, bạn sẽ suy nghĩ cẩn thận về những gì nó dự định làm.

Nếu đó là một ngôn ngữ mới, được giải thích để thay thế JavaScript thì bạn sẽ muốn có một cách tiếp cận rất hay để tiếp cận các nhà phát triển web với khoảng chú ý hạn chế và mong muốn có kết quả ngay lập tức - hoặc nhanh hơn nếu có thể.

Nếu nó sẽ được sử dụng cho nhiệm vụ tiếp theo với Titan, thì các thông số kỹ thuật cực kỳ chi tiết cho thấy bằng chứng chính thức về hành vi của từng thành phần sẽ là mức nhập tối thiểu.

Vì vậy, nó không phải là một điều đơn giản. Để tiếp cận đặc điểm kỹ thuật, có lẽ bạn sẽ tốt hơn nếu có được nhiều kinh nghiệm trong việc tạo ngôn ngữ của mình và cũng làm việc với những người thực sự sử dụng chúng hàng ngày. Nếu bạn có nạn nhân sẵn sàng ... er ... nhà phát triển, tại nơi làm việc có thể dành chút thời gian để học ngôn ngữ của bạn thì họ có thể cung cấp cho bạn phản hồi về những gì cần thiết để khiến họ sử dụng nó.

Nói tóm lại, hãy giữ nó đơn giản và nhiều người sẽ sử dụng nó.

Wirth đã thiết kế và triển khai nhiều ngôn ngữ lập trình: trong số này, các thông số kỹ thuật cho các ngôn ngữ Oberon và Oberon2 đáng chú ý vì có sự hoàn chỉnh, chặt chẽ và dễ đọc.

Lisp và Haskell thông thường có tiêu chuẩn ngôn ngữ. Ruby và Python có triển khai và tài liệu. Vì vậy, tôi sẽ nói rằng một tiêu chuẩn ngôn ngữ là không cần thiết, nhưng nó có thể hữu ích nếu bạn mong đợi có nhiều hơn một ngôn ngữ bạn đang thiết kế. Mặt khác, một tiêu chuẩn là quá sớm nếu bạn mong đợi những thay đổi đáng kể trong định nghĩa ngôn ngữ của bạn.

bất kỳ đặc điểm kỹ thuật nào cũng phải thật ngắn gọn và có thể đứng vững trước thử thách của thời gian

đây là lý do tại sao bạn thấy một sự trừu tượng như BNF được sử dụng cho nhiều tiêu chuẩn ngôn ngữ ... nó ngắn gọn và sẽ vẫn được hiểu lâu sau khi nhiều công cụ hiện tại của chúng tôi bị bỏ lại.

tất nhiên có nhiều thứ hơn là ngữ pháp. nhìn vào những gì người khác đã làm ... perl6, lược đồ, C ... họ giải quyết các vấn đề mà người thực hiện cũng quan tâm.