Здравствуйте, STDray, Вы писали:

STD>В идеале, пользователь вообще не должен задумываться о том, какие символы скобок ему можно вбрасывать, а какие — нет. Поэтому решил, что раз виртуальные скобки вполне реальны, надо минимизировать шанс коллизий с пользовательской грамматикой. По идее http://en.wikipedia.org/wiki/Private_Use_Areas как раз для этого и существует.

Тут

Автор: WolfHound
Дата: 02.10.14

Вольфхаунд подкинул интересную мысль.

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

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

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

Но если есть мысли, то озвучивайте. Реализуем, если будет годная модель.

STD>>>как дружить все это дело со студийной интеграцией
STD>Вопрос открытый. Потому что нет идей, как, допустим, параметризовать SourceSnapshot кастомным препроцессором во время работы интеграции. Или, допустим, имея наследника SourceSnapshot с зашитой логикой препроцессинга и пересчета, указать интеграции, что надо использовать именно его?

Ну, дернуть функцию перед работай парсера не сложно.

Лучше, конечно, придумать декларативный вариант. Тогда и дергать ничего не пришлось бы.

Кто-нибудь может разобраться в сложностях этого в том же Питоне? Там вроде бы что-то было. Но я уже не помню. Да и с Питоном я плохо знаком.

Как вставить виртуальные скобки уже понятно. Это упрощает проблему. Осталось придумать как описывать принцип преобразования отступов в эти виртуальные скобки.