В статье описана подсистема сбора информации по AST, работа с символами, областями видимость и связыванием.
Сразу извинюсь за орфографию, пунктуацию и опечатки. Статья пока не вчитывалась. В финальной версии мы это все поправим.
Сейчас работаем над:
1. Типизацией Nitra на своей новой версии. Это даст поддержку IDE для самой Nitra.
2. Над деплойментом через NuGet.
3. Квази-цитированием.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Сразу извинюсь за орфографию, пунктуацию и опечатки. Статья пока не вчитывалась. В финальной версии мы это все поправим.
В тексте есть "М описали расчет значений" — видимо подразумевалось Мы
Nemerle — power of metaprogramming, functional, object-oriented and imperative features in a statically-typed .NET language
Re[2]: [Nitra] Описание подсистемы сбора информации «Nitra» (предва
Споткнулся об token Reference — если на token Name есть явная ссылка, то для Reference явная ссылка только в месте где переменная используется (но там не должно быть "var", а в token'е !Keyword есть), и как Reference возникает в объявлении (иначе зачем там !Keyword) — не совсем понятно.
Всё остальное понятно, но я за проектом слежу, все предыдущие статьи читал и коммиты просматриваю. Если и замечаю места которые хочется прояснить — то далеко за пределами вводной статьи, типа взаимодействия коллекторов с расширениями грамматики, и т.п.
Ещё одно замечание — в примере калькулятора сначала идёт код с номерами строк, а потом описание с ссылками. Для печатной статьи лучшего варианта наверное и нету, для веба было бы легче если бы описание того что делается появлялось при наведении/клике на строку. Если надо — могу сляпать подходящий JS для такого "интерактива".
Также основной акцент во всех статьях делается на расширении уже существующего языка (наглядный способ ввода новых precedence — это супер). Но имхо, полностью возможности можно было бы увидеть на примере в котором по шагам создаётся язык (пусть только с add/sub), потом расширяется (mul/div и скобки), и после этого создаётся язык-обёртка, в который последняя конструкция плавно встраивается. Собственно я этот путь в свободное от работы время сейчас пытаюсь пройти. Это интересно из-за того что есть всякие Razor-подобные DSL которые расширяются шарпом для получения специфической функциональности, и судя по гуглу "ASP.NET Template Engine" — их уже легион, и каждый — кандидат на переписывание на Nitra.
Re[4]: [Nitra] Описание подсистемы сбора информации «Nitra» (предва
Здравствуйте, hi_octane, Вы писали:
_>Споткнулся об token Reference — если на token Name есть явная ссылка, то для Reference явная ссылка только в месте где переменная используется
И Name, и Reference — это правило идентификатора. Разделение сделано для того, чтобы еще в грамматике развести имя сущности и ссылку на сущность.
Что касается явных ссылок, то и для Name, и Reference в этом примере есть только по одному применению.
Name используется при объявлении переменной:
syntax VariableDeclaration = "var" sm Name sm "=" sm Expression ";"; // 10
Обрати внимание, что в примере нет маппинга ни для Name, ни для Reference. Вот эти атрибуты создают маппинг автоматом.
_> (но там не должно быть "var", а в token'е !Keyword есть), и как Reference возникает в объявлении (иначе зачем там !Keyword) — не совсем понятно.
Что касается !Keyword, то это демострация того как сделать так, чтобы пользователю выдавалось сообщение об ошибке в случае, если он попытается использовать "var" в качестве имени переменной. В принципе Nitra позволяет не накладывать такое ограничение. Так что если убрать эти предикаты, то можно будет писать код вроде:
var var = 42;
Такое код будет прекрасно работать, но будет "рвать глаз". Вот пример и демонстрирует как это запретить.
Наверно стоит разжевать этот момент в статье.
_>Всё остальное понятно, но я за проектом слежу, все предыдущие статьи читал и коммиты просматриваю. Если и замечаю места которые хочется прояснить — то далеко за пределами вводной статьи, типа взаимодействия коллекторов с расширениями грамматики, и т.п.
Ну, так задавай вопросы. Мы с удовольствием ответим. Это будет полезно и окружающим, и нам.
_>Ещё одно замечание — в примере калькулятора сначала идёт код с номерами строк, а потом описание с ссылками. Для печатной статьи лучшего варианта наверное и нету, для веба было бы легче если бы описание того что делается появлялось при наведении/клике на строку. Если надо — могу сляпать подходящий JS для такого "интерактива".
Идея интересная, но не ясно как это дело вмонитровать в RSDN-овский формат. Там ведь исходно XML. При открытии статьи он преобразуется в HTML через XSLT.
Может просто скопипастить нужные строки по месту?
_>Также основной акцент во всех статьях делается на расширении уже существующего языка (наглядный способ ввода новых precedence — это супер). Но имхо, полностью возможности можно было бы увидеть на примере в котором по шагам создаётся язык (пусть только с add/sub), потом расширяется (mul/div и скобки), и после этого создаётся язык-обёртка, в который последняя конструкция плавно встраивается. Собственно я этот путь в свободное от работы время сейчас пытаюсь пройти. Это интересно из-за того что есть всякие Razor-подобные DSL которые расширяются шарпом для получения специфической функциональности, и судя по гуглу "ASP.NET Template Engine" — их уже легион, и каждый — кандидат на переписывание на Nitra.
В качестве примера для своего языка живущего в отдельном файле с отдельным расширением можно рассматривать реализацию C# (.ncs) и саму Nitra (я сейчас начал реализацию ее типизации на новой подсистеме связывания).
В наших планах опубликовать .ncs в NuGet (как обычном, так и NuGet расширений ReSharper). Это позволит делать расширения для C#. Все кто хочет сделать свой формат могут сделать все по образу и подобию.
Так же нужно вынести в библиотеку найторовский код реализующий работу с пространствами имен для C#-подобных языков. Имея такую библиотеку создать нечто вроде Разора будет совсем очень просто. Естественно, .ncs тоже нужно перенести на эту библиотеку. Это позволит совмещать в одном проекте .ncs и свои форматы, причем они будут порождать единый набор символов и будут обрабатываться как единый проект.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [Nitra] Описание подсистемы сбора информации «Nitra» (предва
