https://qr.ae/pN2BWT

Это несложно, но требует огромной работы, чтобы сделать полученный инструмент практичным.

Во-первых, забудьте о синтаксисе — это в основном решённая проблема, почти в любом языке есть 1+ библиотека для создания синтаксических анализаторов. Если вам нравится Python, библиотека PLY предоставляет вам полный набор поддержки любого синтаксиса. Более того, вы можете полностью отказаться от синтаксического анализатора, используя свой хост-язык (язык реализации) для построения деревьев AST или любой другой интерпретируемой структуры данных по вашему выбору.

Далее, избегайте написания классического компилятора, это скучный и очень ограниченный языковой шаблон. Присмотритесь к C++, изначально он был чистым компилятором, но в последнее десятилетие он превратился в свихнутый интерпретатор, работающий поверх движка шаблонов/типов. Именно, он запускает какой-то код во время компиляции, но «язык» для метапрограммирования с его семантикой и синтаксисом сжигает ваш мозг, и у вас всё еще нет инструментов для его отладки.

Не забывайте: любой интерпретатор языка программирования может компилировать самый быстрый машинный код, или код на любом другом языке программирования, который вы хотите использовать (ассемблер, LLVM, C/C ++, Java, ..., все, что вы хотите, включая скрипты сборки и SQL): достаточно писать в текстовые файлы, и компилировать их с помощью любого backend-компилятора.

• Напишите свой собственный интерпретатор, .. НЕТ! Просто используйте любой хост-язык (язык реализации), который вам нравится, предпочтительно динамический, например Python JavaScript Clojure Haskell ... PHP 8-)
• Найдите какую-нибудь структуру данных, которая может обеспечить представление программ — я предпочитаю объектные графы, они могут изначально представлять всё, от AST/атрибутной грамматики целевого языка до любых моделей из прикладной области и концепций архитектуры программного обеспечения.
• Напишите набор методов .compile_to _ *() для этой структуры данных, которые могут компилировать каждый тип узла объектного графа в язык, который вы хотите использовать (LLVM, ассемблер, C, код Python для стека Django + JavaScript,..) — теперь вы можете скомпилировать структуру данных в целевой язык. Обратите внимание, что ваши модели могут компилировать сами себя через генерацию кода.
• Теперь вы уже можете компилировать код, используя интерпретатор вашего host-языка (я использую обычный Python) в качестве компилятора. Фактически, вы уже написали свой язык, не написав его. Вы можете создавать программные системы, описывая их структуру, вы можете строить модели, можете создавать AST-дерево для целевого языка элемент за элементом выполняя выражения на хост-языке, а затем запускать метод AST.compile() и получать код C ++ для backend-компиляции. На данный момент у вас уже есть рабочая версия вашего собственного языка, даже без синтаксического анализатора (хост-язык делает это для вас).
• Затем используйте свой язык практически для написания приложений. Делая это, вы проверяете свой язык на реальных проблемах, и расширяете его каждый раз, когда захотите. Это самый неприятный этап эволюции вашего языка. Больше всего недовольства вызывает написание большого количества кода на хост-языке. Он имеет синтаксис, который вы не считаете идеальным, но вы должны это делать, потому что для хост-яыка есть рабочий отладчик (это обязательный инструмент, без него ничего не заработает) и потому что ваш «язык» (как концепция, определенная в семантике структуры данных) еще не определен для этих вариантов использования.
• Пока ваш (мета)язык развивается, вы обнаружите, что создаете какие-то шаблоны кода, некоторые группы элементов повторяются снова и снова, и их можно абстрагировать как следующую высокоуровневую концепцию. В этом преимущество этого сложного метода - вы можете неограниченно и свободно расширять семантику своего языка, особенно если ваш хост-язык имеет широкие возможности наследования (например, Python с его множественным наследованием, переопределением операторов и динамикой).
• Наконец, наступил самый волшебный этап. Ваши структуры данных, которые представляют одновременно и ваш код и данные (гомоиконичность!), являются активными исполняемыми структурами данных. Они также могут работать через само-интерпретацию: вы можете применить один объектный граф к другому графу, даже к самому себе, в итоге вы получаете в руки преобразования кода/данных и самомодификацию программы.
• Пришло время погрузиться в классическую информатику: SICP, PLAI и PAPL, алгоритмы, шаблоны разработки программного обеспечения и TAPL. Не зацикливайтесь на странных языках программирования, которые используются в этих книгах. Сосредоточьтесь не на синтаксисе, а на идеях и семантике блоков кода в этих книгах. Если вы сможете это понять, то сможете реализовать заново и использовать в реальной работе. Некоторые концепции, описанные в этих книгах, очень эффективны в программировании, но, к сожалению, недоступны в ваших любимых популярных языках, например, сопоставление с образцом или логическая унификация. Однако теперь это не проблема — вы уже реализовали уровень языковой абстракции, так что вы пишете код, который выглядит для других как сложный код на Python, но на самом деле вы пишете на своем собственном языке (определённом на данных). Итак, вы просто можете утащить эту магию в свою вселенную.

Итак, давайте в целом.

Недостаток: сложность метода. Да, огромная, но только на более поздних этапах. На начальных этапах вы просто копипастите некоторые части кода на целевом языке в виде обычных строк (в большинстве программных проектов используется несколько языков: код, скрипты сборки/развертывания/обслуживания, JS/HTML, SQL, ...), иногда заменяя крошечные элементы в этих строках используя Python-код, и пишете их в текстовые файлы. Это выглядит просто даже для новичка: только интерполяция строк и запись текстового файла.

Следующий этап развития вас как программиста — это вязание структур данных. Также выглядит как типовой навык любого программиста: манипулирование графом объектов, которые ссылаются друг на друга, иногда циклически. Это не страшно, используется практически в любой зрелой программной системе. У вас даже есть преимущество: объектный граф -- это унифицированная структура данных, любой узел это экземпляр, унаследованный от базового класса Object, и вы можете работать с ними через унифицированный интерфейс. Каждый унаследованный класс имеет собственное поведение, но все они разделяют одну и ту же концепт: дерево (граф) атрибутной грамматики . Каждый объект является контейнером данных (даже Primitive), каждый узел может иметь произвольные атрибуты, привязанные к другим объектным графам, и каждый узел может иметь упорядоченные подграфы:

## @brief базовый класс узла объектного графа
## @ingroup object
class Object:
    ## конструктор
    ## @param[in] V заданное скалярное значение
    def __init__(self, V):
            if isinstance(V, Object): V = V.val
        ## имя символа / скалярное значение (строка, число,..)
            self.val = V
        ## слоты = атрибуты = словарь = environment
            self.slot = {}
        ## вложенные AST = вектор = стек = очередь
            self.nest = []
        ## глобальный storage id
        ## @ingroup persist
            self.gid = self.sync().gid