Як мені почати писати специфікацію мови програмування?

Мені дуже подобається дизайн мови програмування. Іноді я думаю, що мої мовні проекти та їх потенційні користувачі отримають користь від документа про всебічні стандарти. Я переглянув багато мовних стандартів, починаючи від дуже формальних (C ++) до досить неформальних (ECMAScript), але я не можу реально зрозуміти, як мені слід розбити речі та організувати такий документ, хоча я думаю, що я досить добре в технічному написанні взагалі.

Чи слід писати це як довгий підручник або більше як формальний папір з математики? Як я можу його оновлювати, якщо я розробляю його разом із еталонною реалізацією? Чи варто просто відмовитись і розглядати реалізацію та документацію як фактичний стандарт? Крім того, чи є справді якась користь від того, щоб мати стандарт? Чи означає, що вимога стандарту означає, що мова непотрібна?

Я знайшов специфікацію мови Java як формальною, так і читаною, і я думаю, що вона має розумну структуру. Деякі технічні характеристики W3C також можуть бути хорошими прикладами.

Виконання формальної роботи може допомогти вам зменшити складність мови та побачити кутові випадки.

Заголовки демпфують: кодування джерел, лексика, основні типи, літерали, оператори, вирази, прості висловлювання, умовні умови, цикли, функції (визначення та виклики), декларації типів, модулі, одиниці компіляції, змінне масштабування, різні види дозволу імен (наприклад, імпорт, методи), модель пам'яті, побічні ефекти, набір тексту, одночасність…

Читайте партії та зберігайте це просто

Створити нову мову важко. Дійсно важко. Але в кінцевому підсумку дуже задоволення, якщо воно стає популярним і справді вирішує проблему, яку люди відчувають у вишуканому вигляді.

Як я вже згадував у коментарях, я б радив вам ознайомитись з мовами, що визначають домен Мартіна Фаулера, з наступних причин:

1. Він заглиблюється у велику практичну глибину щодо того, навіщо вам розробляти мову
2. Є деталі, як це зробити (аналізатори, лексичні аналізатори, мовні верстати тощо)
3. Є докладні інструкції щодо впровадження обраного синтаксису для обробки таких понять, як закриття, примітки, буквальні списки, динамічний прийом тощо

Щодо того, як слід писати свою специфікацію, подумайте про свою аудиторію. Очевидно, перед тим, як класти палець на клавіатуру для розробки вашої мови, ви добре подумали, що вона має на меті зробити.

Якщо це нова, інтерпретована мова, яка замінить JavaScript, то вам потрібно дуже підхід, щоб досягти веб-розробників з обмеженим проміжком уваги та бажанням негайних результатів - або швидше, якщо це можливо.

Якщо він буде використаний під час наступної місії на "Титан", то надзвичайно детальні технічні характеристики, що показують точні формальні докази поведінки кожного компонента, будуть мінімальним рівнем вступу.

Отже, це не просто. Щоб підійти до специфікації, вам, ймовірно, буде краще отримати великий досвід у створенні своїх мов, а також працювати з тими, хто фактично ними користується щодня. Якщо у вас є бажаючі жертви ... е ... розробники, на роботі, які можуть зайняти деякий час, щоб вивчити вашу мову, то вони можуть дати вам відгуки про те, що потрібно, щоб змусити їх використовувати.

Коротше кажучи, будьте простою і більше людей використовуватиме її.

Вірт розробив і реалізував багато мов програмування: з них специфікації для мов Oberon та Oberon2 відрізняються повнотою, короткочасністю і читабельністю.

Звичайні Лісп і Хаскелл мають мовні стандарти. У Ruby та Python є реалізації та документація. Тож я б сказав, що стандарт мови не потрібен, але це може бути корисно, якщо ви очікуєте, що там буде більше, ніж одна реалізація мови, яку ви розробляєте. З іншого боку, стандарт є передчасним, якщо ви очікуєте суттєвих змін у мовному визначенні мови.

будь-яка специфікація повинна бути короткою і здатною витримати випробування часом

саме тому ви бачите абстракцію на зразок BNF, яка використовується для багатьох мовних стандартів ... її стислий характер і все ще буде зрозумілий довгий час після того, як багато наших сучасних інструментів залишилися позаду.

звичайно, в цьому є більше, ніж просто граматика. подивіться, що зробили інші ... perl6, схема, C ... вони стосуються питань, які також хвилюють виконавця.