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

B>Имеется ввиду "один бинарь под все студии" или что-то ещё?

Ранее (точнее, пока) была одна интеграция поддерживающая любые языки созданные на базе Nitra. Нужно было только прописать язык в NitraGlobalConfig.xml.

B>Вот тут не совсем понятно. Если ограничения есть, они в любом случае должны хакаться/обходиться — разве это связано с версиями?

Студия расчитана на статическую регистрацию плагинов для каждого языка. Это верно для всех видов расширения (MPF, MEF, ReSharper plagin).

B>....и тут мы окончательно запутываемся в том, по какому критерию мы теперь разделяем плагины!

Один язык — один плагин. Под языком понимается формат файла. Ну, там .cs, .cshtmp, .n, .json...

B>Какие языкИ (мн.ч.) имеются ввиду??? Я думал, у нас будущее состоит из одного языка — Нитры,

Ну, дык разобрался бы давно что такое Nitra. Это мета-язык. У нее есть свой формат .nitra и для него будет свой, отдельный плагин.

B>...для студий 2008/2010/2013 и теперь уже 2015.

Что касается поддержки версий студий, то тут есть вопросы. Возможно мы отсечем старые версии студий. Причем пока не ясно будет ли это начиная с VS 2013 или сразу с VS 2015. А может будем поддерживать начиная с VS 2010.

B>Не совсем понятно... "расширяемый парсер" ведь и так был киллер-фичей Немерли, не? В смысле мы делаем "using Модуль-Синтаксис" и у нас расширенный парсер для нового синтаксиса.

Сейчас нет механизма чтобы реализовать нечто вроде того что используется в Nemerle, когда using в файле может изменить грамматику "на ходу". Сейчас можно только перед парсингом собрать парсер из разных модулей. Сейчас же работа ведется непосредственно над средствами для реализации using-расширяемости или чего-то вроде этого.

B>А!А!А!А!! два месяца — это "невелик"?! На фулл-тайме это очень даже велик!

Сядь, попробуй сделать. Может получится быстрее. Я на всякий случай дал запас.

B>А можно написать что это за зверь? "декларации" — это ж объявления всяких штук в языке — переменных, классов.

Некоторое описание будет в статья которую скоро выложим здесь. В двух словах — это нечто воде АСТ-а. Который имеет более простую структуру, над которым удобно производить вычисления и который будет автоматически сериализовываться в рамках солюшена и загружаться при его открытии. В РеШарпере рукописные аналоги называются "кэшами".

Для каждого файла будет создавать набор деклараций который сериализуется и доступен все время. Ну, а они, в свою очередь, будут использоваться для автоматического получения символов. Символы же это метаинформация. Нечто вроде компайл-тайм рефлексии или немерловых билдеров (TypeBuilder, MethodBuilder, ...).

Мы предоставим не захардкоженные решения (как в Немерле), а инструмент позволюящий легко получать свои типы символов и проецировать на них разбираемый код. Общая схема: код в виде текста -> декларации -> символы. Дерево деклараций создается для каждого файла. Символы уже не привязаны к файлам. Например, паршал-класс может иметь несколько деклараций, но один символ.

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

B>Ух ты! А как конструктор может связывать символы с типами, если он просто конструктор и не знает, кто в языке кто? Это ж проектировщик языка решает: у нас есть слово в кавычках — значит это название типа.

Я не понял что/кто понимается под конструктором. Так что отвечу на счет типов. Типы — это один из видов символов. Мы не будем выделять типы отдельно. Мы предоставим инфраструктуру для описания символов и отображения на них кода. Поддержку именно типов можно будет поместить в библиотеки.

B>Круто! Т.е. текущая стадия завершается созданием полноценного конструктора?

Что за конструктор? Что ты под этим понимаешь?