Застрял

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

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

Что тут можно предложить?

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

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

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

Одно понятно, задача нетривиальная и малой кровью переиспользования существующих компиляторов leaf/lomo как мне кажется нерешаема. Может быть, для начала стоит перевести на общие рельсы имеющиеся системы, что в целом равносильно их переписыванию.