Парсер для Односкрипта

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

Недавняя ошибка в гитсинке показала, что помимо модульного тестирования, с которым ещё не все на «ты», библиотекам явно требуется статический анализ: если процедура принимает 7 параметров, а передаём 8 — это должно отсекаться не тестами, а сразу, при сборке скрипта.

Попытаюсь собрать все потребности воедино, чтобы понять конечный интерфейс для разрабатываемого парсера:

  • Статический анализ:
    • Компиляция — не должно запускаться то, что не сможет работать;
    • Оптимизация — тут можно придумывать вечно; для начала: неиспользуемые переменные, константные вычисления.
    • Документация — извлечение документации к методам;
    • Документация — Предупреждение, что для экспортного метода нет документации;
  • Покрытие тестами: тут надо различать значащие и незначащие строки (комментарии, ветвления в одной строке).
  • Форматирование: приведение к единообразному стилю. Привет, `go fmt` !
  • DSL: возможность в ОдноСкрипте парсить односкрипто-подобные скрипты. Скрипты в скрипте! Больше скриптов!

Отсюда парсер не должен быть, как сейчас, вещью в себе: он должен быть доступен либо напрямую из языка, либо через компоненту, либо через командную строку (`oscript -ast`).
Важно, чтобы парсер спокойно отрабатывал на синтаксически неверном коде. Важно, чтобы сохранял данные о языке использованных ключевых слов. Важно, чтобы для каждой лексемы сохранял данные о положении в исходном коде (строка, столбец начала и окончания). Желательно, чтобы мог работать и как простой лексер, и как построитель дерева.

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


Comments are closed.