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

CU>1) При использовании конвертера CSharpToNemerle который получает в результате Ast Nemerle, ему на вход в конструкторе требуется ManagerClass, откуда его взять?

Он есть у многих объектов. Например, у тайпера:

def typer = Macros.ImplicitCTX();
typer.Manager

CU>Если мы в обычной программе, а не в макросе, Создать самому?

В обычной программе его взять не откуда, так как это часть компилятора. Только зачем он в обычной программе? Он нужен в интеграции с IDE. Там такой объект есть. Для каждого проекта заводится так называемый Engin. Engin является наследником
ManagerClass.

Если хочется из обычного приложения его получить, то пидется вручную создавать ManagerClass и инициализировать его. Это не очень просто, но возможно.

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

CU>Он инициализирует некоторые структуры только при вызове Run, как его инициализировать до этого, чтобы полноценно распарсить C# и получить Ast Nemerle для последующей обработки?

Пример использования ManagerClass можно подсмотреть в коде интеграции со студией, как я уже говорил, там создан наследник класса ManagerClass — Engin. Еще одним примером может служить проект к статье Разработка простого генератора отчетов с помощью Nemerle и System.Xml.Linq

Автор(ы): Владислав Чистяков aka VladD2
Дата: 17.07.2008
Статья демонстрирует разработку реального приложения на Nemerle на примере создания простого генератора отчетов. Кроме того, в статье показана работа
с XML средствами LINQ to XML.

. В нем я парсил выражения с помощью компилятора немерла.

CU>2) Куда все это положить, я начал делать у себя в своей папке, думаю сделать метод PrintBody в TopDeclaration как в методе ClassMember, сам TopDeclaration сделать partial и вынести код печати в отдельный исходник, которому как в ClassMember передается LocatableTextWriter, и он сам себя должен распечатать в него. То есть объединить генерацию исходника Nemerle из C# с генерацией обычного отладочного кода Nemerle, чтобы не делать двойную работу. Может кто придумает вариант с местоположением лучше.

Мне кажется лучше сделать отдельный файл и модуль (на подобии PrettyPrint.n). Создать рядом еще один файл с именем вроде TopDeclarationsPrettyPrint.n и разместить в нем модуль содержаций по одному методу на каждый тип АСТ-веток.

CU>3) Исходник в parsetree ncc будет наверное называться TreePrint.n, или PrintTree.n есть у кого варианты лучше?

Все АСТ — это дерево. Оно как-то не внятно. Лучше TopDeclarationsPrettyPrint.n.

CU>4) Ничего если я сделаю открытыми типы LocatableTextWriter и LocatingTextWriter в Nemerle.Compiler чтобы работать из внешнего кода с ними, из своей библиотеки, чтобы тестить код без перекомпиляции всего Nemerle?

LocatableTextWriter — можно сделать публичным. Но LocatingTextWriter точно не надо. Это всего лишь подкласс класса LocatableTextWriter с переопределенными методами. Знание о его наличии не даст никаких дивидендов. Нужно грамотно капсулирование его использование и все.

CU>5) Также для этого нужен открытым метод ClassMember.PrintBody можно ли его открыть, или это даст брешь в архитектуре компилятора?

Вот это не нужно. Лучше пусть весь код PrettyPrint-а лежит в отдельном модуле и получает доступ к АСТ через публичный интерфейс.

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

CU>6) Встает проблема с генерацией namespace, парсер CSharpToNemerle в результате дает ParseResult в котором есть список TopDeclaration, понятно что каждый из них находиться в своем namespace может в одном а может и в разных. Тут надо как то придумать как создавать пространства имен, как в исходном тексте C#, если есть Location можно как то отсортировать по ним сами пространства, а потом вложить их друг в друга как они должны быть и в них раскрывать TopDeclaration, может кто предложит вариант лучше?

Это косяк заложенный в компилятор Н еще на самых ранних стадиях его разрботки. Поляки увлеклись оптимизацией и опустили некоторые нужные структуры данных.

Насколько я знаю парсер C#-а выдает АСТ в том виде в котором он был спарсен из файла. При этом там есть и информация об пространствах имен. Наверно имеет смысл вынимать эту информацию из необработанного (C#-ного) АСТ. Конкретнее, из типа NamespaceNode.