Обострение в функциональном комьюнити

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

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

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

Комбинаторы парсеров на LINQ

Таки дорвался использовать Monadic Parser Combinators. Достаточно удобно, можно думать категориями Parsec-а, но ошибки компилятора или стеки вызовов при рунтайм-ошибках выглядят ужасающе.
Кстати, по моему, там TValue[] в Rep и Rep1 надо на IEnumerable заменить

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

Теперь думаю, куда бы это контекст со списком парсеров(которые изменяются по ходу разбора) засунуть. Тут подсказали стрелки, но как оные стрелки впихнуть в дотнет и LINQ это отдельный вопрос. Наверно, имеет смысл список парсеров (вернее map идентификатор -> парсер) поселить вместе со входным списком токенов и наколбасить хитрых парсеров, которые кроме того, что потребляют токены, еще и меняют список.

Ну и еще совсем непонятно, как это все будет работать в отсутствие ленивости и оптимизации хвостовых вызовов.