Сейчас ведутся работы над:
1. Nitra.LanguageCompiler.exe — компилятором поддержки IDE для языка. От универсального плагина решили отказаться. От части из-за большого количества хаков необходимых для обхода ограничений студии, а от части по просьбам трудящихся, так как не раз высказывались мнения, что лучше иметь отдельные плагины для каждого языка.
Nitra.LanguageCompiler.exe — это утилита командной строки которая принимает на вход файл вроде этого:
language NitraCSharp
{
span class Char = #FF0000;
span class InlineComment = #008000;
span class MultilineComment = #008000;
extension = .ncs;
company = Jet Brains;
syntax module CSharp.Main start rule CompilationUnit;
syntax module CSharp.Linq;
}
На выходе получается проект интеграции с VS. Скомпилировав его мы получаем *.vsix-файл который можно непосредственно инсталлировать в Студию.
В генерируемом проекте, на сегодня, поддерживаются:
1. Подсветка.
2. Фолдинг/оутлайнинг.
3. Отображение ошибок парсинга.
4. Автодополенине ключевых слов и прочих литералов (контекстное, по грамматике).
Степень готовности Nitra.LanguageCompiler.exe — почти завершен. Но его его нужно интегрировать в инсталлятор и процесс сборки. Так что пока код не перенесет в "мастер".
Над проектом работаю я.
2. Ведутся работы над расширяемостью парсера во время парсинга. Это нужно чтобы, например, реализовать на Nitra компилятор и IDE-плагин для Nemerle.
Степень готовности — проектирование. Объем работ там не велик. Думаю, за месяц-другой завершим.
Над проектом работает Wolfhaund.
3. Синтаксис декларативного отображения дерева разбора на декларации (что-то вроде AST-а). Это часть подстистемы типизации. Еще нужно создать отображение с деклараций на символы и язык описания символов.
Степень готовности — в работе. Сейчас Hardcase прикручивает поддержку специализированного паттерн-матчинга, чтобы можно было осуществлять не тривиальное отображение.
Работы ведет Hardcase.
Дальнейшие усилия будут сосредоточены на подсистеме связывания и типизации, а так еж интеграции всего этого в IDE и ReSharper.
По завершению этого этапа можно будет начать разработку новой версии Немерла (без хаков и компромисво).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали: VD>1. Nitra.LanguageCompiler.exe — компилятором поддержки IDE для языка. От универсального плагина решили отказаться.
Имеется ввиду "один бинарь под все студии" или что-то ещё?
VD>Отчасти из-за большого количества хаков , необходимых для обхода ограничений студии....
Вот тут не совсем понятно. Если ограничения есть, они в любом случае должны хакаться/обходиться — разве это связано с версиями?
VD>, а от части по просьбам трудящихся, так как не раз высказывались мнения, что лучше иметь отдельные плагины для каждого языка.
....и тут мы окончательно запутываемся в том, по какому критерию мы теперь разделяем плагины! Какие языкИ (мн.ч.) имеются ввиду??? Я думал, у нас будущее состоит из одного языка — Нитры, для которого будут генериться плагины, отдельно для студий 2008/2010/2013 и теперь уже 2015. "Нитра" — здесь я сильно упростил, имея ввиду "конструктор языка + язык на этом конструкторе, сильно напоминающий Немерле, но на ступень выше".
VD>2. Ведутся работы над расширяемостью парсера во время парсинга. Это нужно чтобы, например, реализовать на Nitra компилятор и IDE-плагин для Nemerle.
Не совсем понятно... "расширяемый парсер" ведь и так был киллер-фичей Немерли, не? В смысле мы делаем "using Модуль-Синтаксис" и у нас расширенный парсер для нового синтаксиса.
VD>Степень готовности — проектирование. Объем работ там не велик. Думаю, за месяц-другой завершим.
А!А!А!А!! два месяца — это "невелик"?! На фулл-тайме это очень даже велик!
VD>3. Синтаксис декларативного отображения дерева разбора на декларации (что-то вроде AST-а).
А можно написать что это за зверь? "декларации" — это ж объявления всяких штук в языке — переменных, классов.
VD>Дальнейшие усилия будут сосредоточены на подсистеме связывания и типизации
Ух ты! А как конструктор может связывать символы с типами, если он просто конструктор и не знает, кто в языке кто? Это ж проектировщик языка решает: у нас есть слово в кавычках — значит это название типа.
VD>По завершению этого этапа можно будет начать разработку новой версии Немерла (без хаков и компромисво).
Круто! Т.е. текущая стадия завершается созданием полноценного конструктора?
Здравствуйте, 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>Круто! Т.е. текущая стадия завершается созданием полноценного конструктора?
Что за конструктор? Что ты под этим понимаешь?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Сейчас ведутся работы над: VD>1. Nitra.LanguageCompiler.exe — компилятором поддержки IDE для языка. От универсального плагина решили отказаться. От части из-за большого количества хаков необходимых для обхода ограничений студии, а от части по просьбам трудящихся, так как не раз высказывались мнения, что лучше иметь отдельные плагины для каждого языка.
VD>Nitra.LanguageCompiler.exe — это утилита командной строки которая принимает на вход файл вроде этого: VD>... VD>На выходе получается проект интеграции с VS. Скомпилировав его мы получаем *.vsix-файл который можно непосредственно инсталлировать в Студию.
VD>В генерируемом проекте, на сегодня, поддерживаются: VD>1. Подсветка. VD>2. Фолдинг/оутлайнинг. VD>3. Отображение ошибок парсинга. VD>4. Автодополенине ключевых слов и прочих литералов (контекстное, по грамматике).
1) Можно ли как-то собрать интеграцию со своим текстовым пропроцессором (в продолжение разговора про языки с indented синтаксисом)?
2) Я правильно понимаю, генерируется только поддержка студией для определенных расширений файлов, но не для новых типов проектов?
3) Существуют ли механизмы для создания автодополнения руками?
Здравствуйте, STDray, Вы писали:
STD>1) Можно ли как-то собрать интеграцию со своим текстовым пропроцессором (в продолжение разговора про языки с indented синтаксисом)?
В принципе, можно. Интеграция генерируется по шаблонам лежащим тут.
В них можно подменить создание экземпляра класса Language на собственный наследник и реализовать в его методе Parse() препроцессирование.
Генерируемый код использует проект Nitra.VisualStudio в котором лежит универсальный код поддержки IDE.
Если что не так можно править этот проект и проект генератора и предлагать нам свои пул-реквесты. Если что можно трясти меня по скайпу.
STD>2) Я правильно понимаю, генерируется только поддержка студией для определенных расширений файлов, но не для новых типов проектов?
Пока, да. В ближайшее время мы займемся и поддержкой проектной системы. Только код поддержки проектов для новых языков мы, наверно, создавать не будем. Мы будем поддерживать эти языки в любых проектах (например, в C#-ном). Но построение символов для всего проекта (и даже для солюшена) поддерживаться будет.
STD>3) Существуют ли механизмы для создания автодополнения руками?
Студию можно расширять независимо. Можно сделать свой CompletionSourceProvider который будет добавлять элементы в список дополнения.
В будущем мы будем автоматически предоставлять автодополнение на базе типизации. Но, всегда можно сделать свой вариант реализовав ICompletionSourceProvider и другие (к сожалению это не тривиально) интерфейсы.
ЗЫ
В любом случае мы открыты для сотрудничества и готовы допиливать код так чтобы он был максимально универсален. Ну и, конечно же, мы готовы принимать пул-реквесты с доработками. Так что Nitra — это не закрытый ящик.
Так что можешь заняться поддержкой препроцессора, а мы поможем чем сможем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
