Язык N

Проект языка программирования хранимых процедур.

Добро пожаловать.

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

Цели реализации транслятора

• Лексический анализатор текста
• Синтаксический анализатор текста
• Семантический анализатор текста
• Генератор кода обработки данных
• Генератор вызывающего кода
• Интерфейс пользователя

Цели реализации языка

• Синтаксис
• Цикл работы и взаимодействия программы на языке с БД и вызывающим кодом

Цели оптимизации

• Продвинутая аллокация памяти для объектов и их наборов (напр., векторов).

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

  В ходе размумия обнаружились следующие варианты решения проблемы:

  • Промежуточный слой между вызовами аллокации из приложения и системным аллокатором, который будет заниматься тем, что уменьшит количество аллокаций путём переиспользования памяти.

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

  Оба эти подхода решат проблему в той или иной мере, однако, ни один из них не предлагает "мягкого" перехода на новый подход. К тому же, готовых решений для Rust не было найдено. Это означает, что потребуются значительные временные затраты для решения проблемы множественных обращений к системному аллокатору.

• Продвинутый анализ объектов, основанный на селекторах и контекстах.

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

  Основная идея в том, что каждое правило знает какой контекст и какой элемент ожидает получить, а система оповещения, зная о всех правилах, сообщает новые собъекты именно тем, кому они нужны.

  Переход на реляционную модель хранения сущностей сведут, предположительно, проблему на нет т.к. будет достаточно обычной итерации по данным. Переработка и/или уничтожение под-типов (как, например, преобразование составных данных и операций над ними к набору атомарных) в этом случае будет возможна с помощью разделения поддоменов и динамической диспечеризации.

• Лаконичный API.

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

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

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

• Меньшее использование стэка.

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

Построен на

• Язык программирования Rust
• Пакетный менеджер Cargo
• Библиотека комбинаторов парсеров Nom
• Библиотека логгирования Log
• Библиотека логгирования EnvLogger
• Библиотека форматирования вывода во время отладки PrettyAssertion
• Библиотека разбора, проверки аргументов командной строки Clap
• Титанические усилия автора

Авторы

• Дмитрий Демин