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

VD>В ревизии https://code.google.com/p/nemerle-2/source/detail?r=1df85e5d901cc3a553ea09df72ec69eb97933be9 (сори за жуткий номер) я добавил солюшен для компилятора и первый проект Core.

У меня компилятор ругается на ValueOption:

Error    5    unbound type name `ValueOption'    ...

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

M>Тогда вопрос: компилер будет переписываться полностью или у существующего немного подпилят код в сторону модульности?

Код будет переписан чуть менее чем полностью, конечно с оглядкой на существующую базу.

M>Я не вижу каких-то особых причин разделять практически единую сущность. Ну будет больше методов, лишнюю память же они не съедят! Да и extension methods вроде бы есть.

Вообще-то съедят. Они будут как минимум ссылаться на свой PExpr.

M>Как я понял, Влад уже попробовал CCI и его возможностей достаточно. На форуме уже бросаются заготовки классов для метаданных, хотя как и где они будут использоваться — вопрос (думаю, не только для меня? ).

Они используются в компиляторе фактически везде.

M>По сути, даже непонятно, что в компиляторе будет переписываться (см. вопрос выше).

С ходу:
1) Парсер
2) Кодогенератор
3) Механизмы типизации (за исключением алгоритма вывода типов)

В принципе,не так уж и много

_E_>
_E_>Error 5 unbound type name `ValueOption' ...
_E_>

Взял тип ValueOption из исходников nemerle-1 (файл lib\option.n)

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

_E_>У меня компилятор ругается на ValueOption:

_E_>

_E_>Error    5    unbound type name `ValueOption'    ...
_E_>

Да, мы не успели зарелизить последнюю вресию. Пока что просто замени на option.

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

_E_>Взял тип ValueOption из исходников nemerle-1 (файл lib\option.n)

Можно и так. Потом, когда перейдешь на последнюю версию, удали его.

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

H>3) Механизмы типизации (за исключением алгоритма вывода типов)
Вывод типов тоже будет полностью переделан.
То что есть сейчас тормозной глюкодром.

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

VD>>>Завел соответствующий issues.

Поправил перевод, 4 пункт убрал — уж слишком специфичный.

VD>Поясню, что это значит на примере. Предположим у нас есть тип:
VD>

VD>class A[T] { }
VD>

VD>и его наследник:
VD>

VD>class B[X] : A[X] { }
VD>

VD>Если мы захотим получить тип A[X], то нам потребуется подставить...

Пример понял, но вот зачем нужно подставление метаридеру — х/з. Он же ведь просто читает данные о сборке? И если там дженерик тип, он просто читается как другие типы. Или я что-то не догоняю?

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

M>Пример понял, но вот зачем нужно подставление метаридеру — х/з. Он же ведь просто читает данные о сборке? И если там дженерик тип, он просто читается как другие типы. Или я что-то не догоняю?

Читается он как обычные типы, а вот чтобы использовать, его нужно параметризировать.

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

_E_>Взял тип ValueOption из исходников nemerle-1 (файл lib\option.n)

Вышел релиз-кандидат. Там эта структура уже есть. Стоит перейти на нее.

ЗЫ

Ну, как? Что-нибудь получается? Если есть вопросы, то лучше их задавать заранее.

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

D>могу попробовать сделать вариант с AbsIL.

Ну, как?

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

VD>Ну, как? Что-нибудь получается? Если есть вопросы, то лучше их задавать заранее.

Есть пара вопросов:

1. При реализации ExternalTypeInfo нужно брать реализацию из nemerle-1 и переделывать ее на новый лад, или писать по-новому?
   
   
2. Создал свой клон для CCI. Я правильно понимаю, что нужно сделать отдельный проект? Сейчас я назвал его Core.CCI, может как-то по-другому?

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

_E_>Есть пара вопросов:

_E_>* При реализации ExternalTypeInfo нужно брать реализацию из nemerle-1 и переделывать ее на новый лад, или писать по-новому?

Писать новую. Просто нужно реализовать NTypeInfo из проекта Core, а там уже будем смотреть чего не хватает.

_E_>* Создал свой клон для CCI. Я правильно понимаю, что нужно сделать отдельный проект? Сейчас я назвал его Core.CCI, может как-то по-другому?

CCI трогать не надо. Надо собрать его сборки и использовать уже их. Их нужно положить в ExternalDependencies.

Проект нужно создать для того чтобы разместить в нем реализацию классов из Core. Этот проект можно назвать MetadataReader.

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

_E_>* При реализации ExternalTypeInfo нужно брать реализацию из nemerle-1 и переделывать ее на новый лад, или писать по-новому?

В данной ревизии я добавил интерфейс IReferencedAssembly:

  public interface IReferencedAssembly
  {
    CustomAttributes  : ICustomAttributes { get; }
    Types             : Seq[NTypeInfo]    { get; }
    Macros            : Seq[IMacro2]      { get; }
    Msgs              : list[Msg]         { get; }
    
    event Changed : EventHandler;
  }

Вот этот интерфейс и нужно реализовать.

Для начала нужно обновить свой клон, чтобы в него попали все изменения внесенные мной.

При реализации нужно постараться выполнить следующие условия:
1. Производить чтение метаданных каждой сборки в отдельном потоке (т.е. код должен быть по потоко-независимым, если это позволяет базовая библиотека).
2. При загрузке типов нужно сначала загружать только минимум информации: Имя, путь (пространство имен), количество параметров типов. Остальное нужно грузить по потребности. Особенно это важно при загрузке членов типов и вложенных типов, так как их может быть очень много.
3. Реализовать чтение атрибутов без загрузки сборок на выполнение.

Основная цель — ускорить первичную загрузку сборок. Так что в тестах имеет смысл замерять время чтения списка типов и формирование списка их имен.

ЗЫ

Желательно комитить промежуточные результаты.

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

VD>Вкратце описание типов которые нужно реализовать:
VD>TypeInfo — описвает базовый абстрактный тип представляющий описание типа в компиляторе. TypeInfo описывает не воплощенный тип, т.е. тип без параметров типов. Его часто так же называют Type Constructor, от чего в компиляторе он частенько появляется в полях с именем tycon.

Изза ской архитектуры довольно таки много проблем с типизацией Дженериков. Даже в самом дотнете есть Type который без заданых дженерик парметров, но когда порождаеться класс (и объект) то создается новый тип, в котором Женериковские параметры уже проставлены.

Иожет и в n2 сделать наследник от TypeInfo для реализованных дженериков. А вообще надо всю систему типизации пересмотреть..

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

BM>Иожет и в n2 сделать наследник от TypeInfo для реализованных дженериков.

Зачем чтобы была такая же путаница как в дотнете?
Для воплощения типов сейчас используется FixedType.Class с параметрами или без.

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

VD>1. Производить чтение метаданных каждой сборки в отдельном потоке (т.е. код должен быть по потоко-независимым, если это позволяет базовая библиотека).

Да тоже всегда думал, что компилятор немерле должен быть много потоковым...

PS. Постараюсь влиться в проект как можно скорее..

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

BM>Изза ской архитектуры довольно таки много проблем с типизацией Дженериков.

Можно привести пример этих проблем?

BM>Даже в самом дотнете есть Type который без заданых дженерик парметров, но когда порождаеться класс (и объект) то создается новый тип, в котором Женериковские параметры уже проставлены.

Я так понимаю что "в самом дотнете" — это значит в System.Reflection? Этот API не лучший пример для подражания.

BM>Иожет и в n2 сделать наследник от TypeInfo для реализованных дженериков.

Делать наследников TypeInfo смысла нет. Я думал об объеденении TypeInfo и FixedType, так как они действительно фактически являются единым целым и не мыслимы друг без друга. Но пока что не нашел для этого достаточно аргументов.

BM>А вообще надо всю систему типизации пересмотреть..

Над этим и работаем.

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

BM>PS. Постараюсь влиться в проект как можно скорее..

Давай! Люди — это самый ценный ресурс.

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

BM>>Иожет и в n2 сделать наследник от TypeInfo для реализованных дженериков.

H>Зачем чтобы была такая же путаница как в дотнете?
H>Для воплощения типов сейчас используется FixedType.Class с параметрами или без.

С FixedType и TypeInfo сейчас не меньшая путаница. Я бы даже сказал — большая.

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


VD>CCI трогать не надо. Надо собрать его сборки и использовать уже их. Их нужно положить в ExternalDependencies.

VD>Проект нужно создать для того чтобы разместить в нем реализацию классов из Core. Этот проект можно назвать MetadataReader.

Я имел ввиду нужно ли в названии проекта отразить, что это реализация чтения метаданных на основе базовой библиотеки cci? Ранее вроде бы говорилось, что предполагается реализовать чтение метаданных на основе разных базовых библиотек, одна из которых cci. Будут ли все эти реализации находиться в одной сборке, или для каждой все-таки нужна своя сборка.