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

K>Влад, спасибо за статью! Она даёт скорее общее понятие как это сделано именно через Нитру + переплетение с классикой (разрешение имён, типизация и т.п.). Что не совсем согласуется с моей схемой, так это наличие двух деревьев — PT & AST — у меня всё в одном. Вот это AST — без него совсем никак?

В простых случаях можно без AST. Но, в сложных (большие проекты, сложные языки) уже будет проблематично. По AST будут создаваться типы для символов.

К тому же есть еще одна проблема. Мы хотим оставить синтаксис чистым. По этому все вычисления мы вынесли в AST.

K>Знать что-то из теории или знать что придётся писать? Пока что пишу — ничего особо страшного нет. Даже немного раскрашивается код Затыки пока только архитектурного плана — что и где хранить.

Интеграция с IDE в ручную подразумевает много чего. Кроме знаний в области создания компиляторов еще нужно изучить всевозможные API IDE/редакторов. Так же нужно обеспечить приемлемую производительность сбора информации о проекте (символов). Это не сложно если расчет делается на один файл небольшого размера, но очень не просто, если расчет делается на большие проекты. Тут уже нужны стратегия кэширования, отложенные вычисления и много чего еще.

Собственно одна из задач Nitra спрятать все эти знания "под капот". Разработчик создает нужные описания, дает их Nitra, а та генерирует весь необходимый код.
Так как описание декларативно, мы развивая Nitra улучшаем поддержку IDE и качество компиляторов без изменения описания языка.

K>Не вопрос, но тут пугают проблемы переходного этапа у Немерле: Нитра пишется на "старом" Немерле, после чего генерит, видимо, немерловый же код, который придётся использовать из того же Немерле (т.к. с C# не всё идеально стыкуется). Но писать на старом Немерле пока не готов, особенно предвидя "новый" Немерле, созданный при помощи Нитры.

Немерл не так сильно отличается от шарпа, особенно в пределах необходимых для написания встроенного в наши DSL кода и прочего обвязочного кода.
Обычно, для начала, достаточно прочесть эту

Автор(ы): Сергей Туленцев, Владислав Чистяков
Дата: 23.05.2006
Производительность труда программиста в основном зависит от самого программиста. Однако даже самый опытный и знающий программист мало что может без подходящего инструмента. Эта статья открывает цикл статей об одном из таких инструментов, еще мало известном среди программистов, но очень многообещающем. Язык Nemerle, о котором пойдет речь в этих статьях, на первый взгляд очень похож на слегка улучшенный C#, но привносит многое из передовых исследовательских языков. Данная статья рассказывает об отличиях Nemerle от C# (как наиболее близкого языка)и является неформальным введением в язык.

и эту

Автор(ы): Чистяков Владислав Юрьевич
Дата: 20.02.2012
Те, кто начинает изучать язык программирования Nemerle после C#, зачастую задаются вопросом, почему при общей похожести языков в Nemerle введены те или иные синтаксические отличия. Эта статься посвящена описанию отличий и объяснению причин их возникновения.

статьи. Немерл даже поддерживает использование C#-файлов в проекте, но в них не будет интеллисенса.

K>Попутный вопрос по новому Немерле: он уже может быть реализован Нитрой, которая доступна сейчас? Или новую будут писать, только когда сама Нитра будет полностью написана?

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

Собственно, поддержка MSIL-а будет полезна и нам. Так что я охотно буду помогать в его реализации. Мы сможем использовать ее для генерации код под дотнет. В наши концепции входит генерация кода переписыванием из более высокоуровневого языка в менее высокоуровневый.

K>И политический момент: почему обязательно превращать всё в "интеграцию" (со студией) ?

Потому что это промышленный стандарт для дотнета и в ней есть весь необходимый функционал. Но ничего не заставляет генерировать код и для других IDE.

K>А если я захочу только парсер?

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

С Nitra идет тестовая утилита. В ней реализована все что поддерживает Nitra на сегодня и будет реализовано все что будет появляться. Можно считать ее микро IDE.

K>Что если сначала полностью допилить Нитру, а потом уже "улучшать её вылоп" в сторону VS?

Мы развиваем все параллельно. Это часть процесса тестирования.