Я вот набросал план того, что нужно сделать чтобы зарелизить 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.

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

В плане — ты упомянул бэкэнд. Это в принципе наверное то, что ты имел ввиду в этой ветке

Автор: fddima
Дата: 19.01.17

, когда я говорил, что как жаль, что нет возможности делать нэйтив.

Я прежде всего хотел бы понять твои личные (они будут ближе всего к правде) — сколько тут работы.

Но тут надо прежде всего понять — что такое есть этот самый бэкэнд и что он даст. Это вообще ключевой момент.


-- всё что ниже — основано на моих представлениях и может содержать логические ошибки --

С моей колокольни (в моих представлениях) — я понимаю, что нитра — освободит от тучи работы, и позволит сосредоточится на плюшках прям на следующей неделе! Я отлично это понимаю. Т.е. для ресерча — это то, что надо, и тут реально остальные альтернативы... скудны. С другой стороны — я понимаю, что, если задачу поставить так: "эта хрень должна быть кросс-компилирована чистым C компилятором (gcc)" — то тут я вижу фэйл. При этом — ни для нитры, ни для языка самого в себе — это не являются проблемами по отдельности. Т.е. скорее смущает то, что нитра — представляет нехилый агрегат, который вдобавок — не так уж легко и переносим. Опять же — оно для дотнета написано с содержанием в уме GC. Прикручивать сторонний — это не проблема. Проблема в том, что, кому-то легче от этого отказаться, чем пытаться вообще в это всё вникнуть.

Опять же, я проясню момент: нитра — и так ясно, отличный инструмент, и я _лично_ не испытываю неудобств с тем, что бы "языковой бэкэнд" работал на дотнете/mono/дотнеткоре/whatever и генерировал то, что он хочет. Тем не менее просто, ммм... разработчиков GP-языков с дотнетом за спиной — привлечь невозможно. Вы не пересадите с питоновских скриптов на что-то другое, — а чего уже тут говорить.

Поэтому — в целом — понятно — или ехать или плюшки. Возвращаюсь к изначальным вопросам — всё таки — что даёт "заложенный изначально" бэкэнд, может ли он быть полностью нативным? Как много кода нужно? Как насчет GC?
Т.е.:
а) мы генерим нативный парсер
б) мы генерим всю нитру нативную
в) ...
?!

С ходу — неясно.

PS: Я так предполгаю, что идея в том, что бы нитра компилировала сама себя нативно. Если так и задатки к этому есть — похвально. Но — тут пожелаю только удачи. С этим в адекватное время не справится и команда профессионалов. Одиночки по вечерам — и подавно. Кроме того, интерес не в том что бы сделать компилятор нитры. Более того, N и N2 и все его последователи на мой _личный_ вкус — неправильные. Просто глупо заниматься разработкой одного, вместо того, что бы заниматься разрабткой того, что хочется. Опять же — для ресерча — эта нативность вообще нафиг не нужна. Поэтому хочется просто прояснить. Тут нет фатализма — как раз наоброт, всему своё место.