В очередной раз задумался, стоит ли использовать при проектировании программ Расширенные Формы Бэкуса Наура (англ. Extended Backus Naur Form), сокращённо РБНФ (англ. EBNF). И дело не только в них, возможно что-то другое подобное, включая различные парсеры.

Локализация ISO/IEC 14977:1996(E) (Extended BNF)

Фактически, если вы можете описать синтаксис языка программирования, который представляет собой инструкции и является ограничением над простым текстом (plain text), то точно так же вы можете описать прочие ограничения, такие как идиомы, паттерны, архитектуры.

Ограничения простого текста.
1. инструкции.
2. идиомы.
3. паттерны.
4. архитектуры.
5. алгоритмы.

Причём в этот список так же входят алгоритмы. Где-то читал, что алгоритмы относятся к шаблонам поведения. Не к шаблонам проектирования поведения, а именно к шаблонам поведения.

Алгоритмы это точно такие же шаблоны как и другие конструкции с точки зрения ограничений. Их можно написать по-разному, но всегда есть предел при заходе за который данный алгоритм перестаёт считаться таковым и очевидно будет назван как-то по другому.

С точки зрения конструирования кода можно выделить операции.
1. Сбор.
2. Разбор.

Сбор используется для конструирования, а разбор для получения исходных конструкций или проверки на правильность набора.

По большому счёту, то о чём я говорю называется метаязыком.

Метаязы́к — язык, предназначенный для описания другого языка, называемого объектным языком.

Я думаю, что каждый программист так или иначе применяет метаязык при конструировании программ, только все ограничения находятся в голове у программиста. Они просто не заданы в явном виде, но они есть. Потом смотришь на их или свой код.

-Видишь суслика.
-Нет.
-И и я не вижу, а он есть.

Кстати, вот почему код не передаёт даже явные задумки, а не только отброшенные варианты. Не факт, что по коду можно создать метаязык использовавшийся для его создания. И как следствие проверить на правильность без самих программистов написавших код тоже нельзя.

1. Если брать ручное создание и проверку, то здесь всё понятно. Берём РБНФ или что ещё и погнали писать правила. Всё делаем ручками, проверяем глазками.
2. А если брать автоматику, то нужен какой-нибудь универсальный парсер. Их так-то не мало, но что-то я так за десятилетия ничего не попробовал на них наваять.

Первое попавшееся.
Нюансы разработки парсера для своего языка программирования

Ведь в жизни практически любого программиста может наступить момент, когда ему в голову приходит светлая идея — разработать свой собственный язык программирования.

В принципе создать метаязык на основе существующих языков таких как C++ или C++ или может быть даже C++ вполне можно было бы. Хотя лично я воспринимаю это лишь как ограничения над конструкциями для получения явных ограничений вопреки неявным ограничениям, которые существуют лишь в мозгах программистов X.

Собственно пока всё это лишь на стадии размышления. Если есть какие-то мысли, практический опыт, видели где-то интересную статью или книгу на эту тему, то поделитесь ниже в комментариях.