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

C>Идеальным для вас вариантом было бы добавить в PExpr ссылку на своего "родителя" в дереве. Но я не уверен, что это будет безвредно для производительности компилятора, которая и сейчас не вызывает комплиментов.

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

CU>> Я думаю может быть стоит сделать расширение этой функции чтобы возможно было узнавать контекст, родительское выражение и все что до него в функции обработки экспрешена, для этого вместо параметра in_match надо сделать полноценную структуру контекст с информацией о родительском PExpr, тогда в один обход будет возможно узнать в каком участке кода мы находимся.

C>Альтернативно, создать отдельное дерево "родительских" отношений между PExpr-ами внутри тела метода и получать контекст уже по нему.

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

C>По моему опыту написания аж двух general-purpose макросов, лучше всего выдрать код из компилятора, оформить в отдельный макропроект, переписать по вашему усмотрению, и после дискуссии с сообществом закоммитить назад в Nemerle

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