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

Подчеркну, что работать над языками (Nemerle 2.x & Cx#) можно уже сейчас. Но я физически не могу разорваться. Если есть желающие, я могу им объяснить, что надо делать и помогать это делать. Бояться, что не справитесь не нужно. Все что нужно объясним.

План на самое ближайшее время:
1. Разобраться с этим extend syntax и маппингом для него (там выявились ошибки).
2. Разобраться с загрузкой символов (новых) из внешних сборок.
3. Допилить типизацию для тех мест, где она не доделана и поправить ее косяки.

После этого у нас, уже будет какой-никакой, а интеллисенс.

После этого можно будет зарелизить первую версию Nitra.

Планы на более далекую перспективу:

	Исправить идеологическую ошибку с деревом символов
	Надо еще исправить косяк, что я заложил в работу с символами (т.е. в проекте DotNetLang.nproj). Сейчас получается так, что символы не могут браться из другого проекта того же солюшена. И приходится их грузить для каждого проекта из референс-сборок. Я их при создании леплю в дерево типов проекта, а это не правильно. Они должны иметь локальные деревья для каждой сборки (проекта). И символы из сборки/проекта надо мапить в разные проекты. Таким образом, дерево, используемое для типизации, должно быть агрегатом деревьев отдельных сборок. А типы из текущей (типизируемой) сборки должны не отличаться от тех, что из сборок загружены. Если это сделать, то решится сразу много проблем: 1. Мы сможем кэшировать символы и переиспользовать их в проектах одного солюшена. 2. Мы сможем не грузить символы из референс-сборок, если у нас имеет место прожект-реферес. Правда, надо еще с видимостью повозиться.

	Исправить косяк с идеологией биндинга и резолва
	Следующий косяк у нас с идеологией биндинга и резолва. Я поглядел то, как делают в Шарпе (Розлине) и понял, что нам надо делать так же. Сейчас у нас сокрытие символов работает так, что если найдется неподходящий символ (например, приватный из другого скопа), то мы его или полностью проигнорируем (отфильтруем) или выберем его, и прекратим поиск (и выдадим не верное сообщение в результате). В Розлине поступают так. Они при биндинге, всегда возвращают амбигус-список и разбираются с ним уже при резолве приехавших результатов. Если у них попадается приватный символ и публичный, они просто отбрасывают публичный и все ОК. Если же у них не находится публичного, они сообщают ошибку о том, что найденный символ имеет неподходящий модификатор видимости.

	Продумать и переделать взаимодействие резолва и автодополнения слов (complit word)
	Еще у нас есть серьезная недоработка с резолвом и автодополеннием идентификторов. Сейчас у нас алгоритм резолва ничего не знает об автодополнении. В результате в список автодополнения уходит все что сбиндилось. А это может быть очень много. Надо как-то научить резолв работать не только с точными совпаденями имен, но и с получаемыми для автодополенения (фильтуемыми по комплит-префиксу). Тут, вообще, надо подумать над тем как это все дело реализовать.

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

	Реализация Nemerle 2
	Далее нужно делать Nemerle 2. Для начала достаточно воспризветси сабсет того, что используется в Nitra.

	Замена кода Nitra написанного на Nemerle 1.x на код написанный на Nemerle 2.x
	Далее надо бутстрапить Nitra на Nemerle 2. При этом придется переписывать макросы и кодогенерацию. Тут объем работ будет большим. Но оно того стоит, так как дальше мы сможем избавиться от Nemerle 1, перенести Nitra на другую платформу и т.п.

После этого можно будет выпустить второй релиз Nitra.

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

Подчеркну, что работать над языками (Nemerle 2.x & Cx#) можно уже сейчас. Но я физически не могу разорваться. Если есть желающие, я могу им объяснить, что надо делать и помогать это делать. Бояться, что не справитесь не нужно. Все что нужно объясним.

План на самое ближайшее время:
1. Разобраться с этим extend syntax и маппингом для него (там выявились ошибки).
2. Разобраться с загрузкой символов (новых) из внешних сборок.
3. Допилить типизацию для тех мест, где она не доделана и поправить ее косяки.

После этого у нас, уже будет какой-никакой, а интеллисенс.

После этого можно будет зарелизить первую версию Nitra.

Планы на более далекую перспективу:

	Исправить идеологическую ошибку с деревом символов
	Надо еще исправить косяк, что я заложил в работу с символами (т.е. в проекте DotNetLang.nproj). Сейчас получается так, что символы не могут браться из другого проекта того же солюшена. И приходится их грузить для каждого проекта из референс-сборок. Я их при создании леплю в дерево типов проекта, а это не правильно. Они должны иметь локальные деревья для каждой сборки (проекта). И символы из сборки/проекта надо мапить в разные проекты. Таким образом, дерево, используемое для типизации, должно быть агрегатом деревьев отдельных сборок. А типы из текущей (типизируемой) сборки должны не отличаться от тех, что из сборок загружены. Если это сделать, то решится сразу много проблем: 1. Мы сможем кэшировать символы и переиспользовать их в проектах одного солюшена. 2. Мы сможем не грузить символы из референс-сборок, если у нас имеет место прожект-реферес. Правда, надо еще с видимостью повозиться.

	Исправить косяк с идеологией биндинга и резолва
	Следующий косяк у нас с идеологией биндинга и резолва. Я поглядел то, как делают в Шарпе (Розлине) и понял, что нам надо делать так же. Сейчас у нас сокрытие символов работает так, что если найдется неподходящий символ (например, приватный из другого скопа), то мы его или полностью проигнорируем (отфильтруем) или выберем его, и прекратим поиск (и выдадим не верное сообщение в результате). В Розлине поступают так. Они при биндинге, всегда возвращают амбигус-список и разбираются с ним уже при резолве приехавших результатов. Если у них попадается приватный символ и публичный, они просто отбрасывают публичный и все ОК. Если же у них не находится публичного, они сообщают ошибку о том, что найденный символ имеет неподходящий модификатор видимости.

	Продумать и переделать взаимодействие резолва и автодополнения слов (complit word)
	Еще у нас есть серьезная недоработка с резолвом и автодополеннием идентификторов. Сейчас у нас алгоритм резолва ничего не знает об автодополнении. В результате в список автодополнения уходит все что сбиндилось. А это может быть очень много. Надо как-то научить резолв работать не только с точными совпаденями имен, но и с получаемыми для автодополенения (фильтуемыми по комплит-префиксу). Тут, вообще, надо подумать над тем как это все дело реализовать.

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

	Реализация Nemerle 2
	Далее нужно делать Nemerle 2. Для начала достаточно воспризветси сабсет того, что используется в Nitra.

	Замена кода Nitra написанного на Nemerle 1.x на код написанный на Nemerle 2.x
	Далее надо бутстрапить Nitra на Nemerle 2. При этом придется переписывать макросы и кодогенерацию. Тут объем работ будет большим. Но оно того стоит, так как дальше мы сможем избавиться от Nemerle 1, перенести Nitra на другую платформу и т.п.

После этого можно будет выпустить второй релиз Nitra.