published: true
После первого прототипа дело o.t. застопорилось и неспроста. Я начал повторять шаги, по которым до меня прошло уже много людей и коллективов, а с коллективами тягаться смысла нет. Поэтому всякие плюшки типа аналога xpath или применения relaxng теперь кажутся неинтересными.
Со встраиванием языков программирования тоже проблема. Получается, что нет возможности встроить языки в шаблонизатор на уровне библиотеки и необязательного компонента. Уже на уровне сканнера символов сталкиваемся с необходимостью двух различных обработчиков одного и того же символа, что само по себе лишает сканнер обероновской простоты. Возможно на этом этапе стоит оформить сканнер и парсер по-другому.
Что тут можно предложить?
Первой на ум приходит мысль о модели производитель-потребитель. Сканнер становится нерасширяемым и монолитным и потребляет любой символ, даже тот, который ему незнаком. Минус очевиден, вся работа по осознанию семантики прочитанного становится задачей потребителя, что не очень хорошо с точки зрения разделения ответственности.
Второй способ довольно банален, монолитный парсер со сменными стратегиями разбора символов. Сканнер включает в себя сразу все возможные символы и предопределенные идентификаторы. Минус очевиден, возможные интерференции между синтаксисами языков внутри сканнера. Сложный компилятор с кучей дублирующегося по сути кода для разных режимов разбора, что почти не решается шаблонизацией или обобщением. Просто чуть разный, но однообразный код.
Третий способ полностью противоречит исходному желанию органично встроить исполняемый код в шаблон, мне придётся реализовать код в шаблонах как полностью отдельную сущность и разделять их с шаблоном уже на уровне текстового представления. Удобный, но антиконцептуальный способ.
Одно понятно, задача нетривиальная и малой кровью переиспользования существующих компиляторов leaf/lomo
как мне кажется нерешаема. Может быть, для начала стоит перевести на общие рельсы имеющиеся системы, что в целом равносильно их переписыванию.