Cx# — это реализация крайней (на данный момент) версии обычного C#, но:
1. На базе технологии Nitra.
2. Cx# будет поддерживать динамическое расширение в стиле Nemerle (точнее, в стиле Nemerle 2).
Многие, наверно, читали пиар-агитки от Майкрософт и полные розовых соплей от сторонних программистов о проекте Roslyn (компиляторах и движках IDE для C# и VB написанных на C# и, чуть-чуть, на VB).
С их помощью можно очень просто отарсить проект или просто кусок кода на C# или VB и вынуть какую-то информацию. Так же они позволяют делать разные анализаторы и прочие утилиты. В общем, штука хорошая.
Кое-кто задумывается и о пользовании Roslyn для задач метапрограммирования. А а некоторые мечтают и о расширении C# нужными им фичами.
Но на практике эти желания трудно осуществимы. Тут уж надо стать совсем уж низкоуровневым разработчиком компилятора. Да и обойтись без прямой модификации исходников Roslyn-а вряд ли выйдет.
Майкрософт пока что не очень хочет отдавать возможность изменения языков и компилятора на сторону. Но самое главное, что дизайн и реализация Roslyn такова, что не рассчитывает на свое расширение через подключаемые компоненты. Так что увидеть своего хитрого оператора, работающего в стандартом компиляторе и движке IDE от MS, у вас скорее всего не выйдет.
А вот Cx# сразу задумывается как допускающий широкие возможности по изменению синтаксиса подключаемыми плагинами (они же синтаксические макросы) и для внедрения на разные стадии компиляции в виде макросов не синтаксических. При этом будет обеспечиваться поддержка полная поддержка IDE и бесшовная интеграция с другими расширениями.
Почему не Nemerle, спросят многие из тех кто знаком с этим языком?
Дело в том, что так вопрос не стоит. Nemerle и расширяемый C# (или Cx#) очень близки. За исключением расширенного паттерн-матчинага и синтаксических различий у Cx# и Nemerle 2 будет все общее. А учитывая, что по возможностям Nemerle будет надмножеством последней версии C# можно сказать, что все что делается для Cx# будет повторно использовано в Nemerle. Ну, за исключением синтаксиса, конечно. Хотя на уровне описания типов (за исключением их членов) и синтаксис будет совпадать.
В Nemerle 2.х планируется отказаться от неоправданных отклонений от спецификации C# в области связывания имен. А в Cx# использовать те отклонения, которые оправданы (имеют практические преимущества). Например, в Cx# будет использоваться более продвинутые алгоритмы вывода типов, а в Nemerle эти алгоритмы будут изменяться так, чтобы в большей мере соответствовать спецификации C#. Например, надо оказаться от вывода типа функции по литералам, так как это приводит к несовместимому с C# разрешению перегрузок и просто выглядит плохим решением.
Например, в Nemerle вот такой код может выдать ошибку при компиляции:
def res = objs.Where(o => o.Foo(1));
так как Немерл на первом проходе не будет иметь информации о типе "o", он выведет тип int из литерала "1" и наложит ограничение на выражение o.Foo. Когда на втором проходе тип "o" будет известен, типизация выражение o.Foo может закончиться ошибкой или может быть выбрана перегрузка отличная от той, что выбрал бы компилятор C#.
По сему нужно пересмотреть алгоритм вывода типов Nemerle в пользу более похожего на алгоритм используемый в C#.
С другой стороны в Cx# будет можно не указывать параметры типов у конструкторов и т.п.
Общий подход к совместимости таков. Cx# должен компилировать код C#, но может делать некоторые вольности, если они не противоречат первому условию.
Естественно, что к Cx# будет доступна библиотека расширений превращающая язык в более мощный. Например, для Cx# будет доступен полноценный немерловый паттерн-матчинг.
Еще одна причина по которой нужно разрабатывать Cx# — это возможность получения в своих языках (например, в DSL-ях) метаинформации из C#. Скажем если вы пишите XAML с человеческим лицом, то вам может захотеться получить список типов или свойств некоторого типа. Часть типов и их членов может быть описана в коде на C#. Наличие Cx# позволит просто и прозрачно получить информацию об этом коде внутри вашего языка.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Cx# — это реализация крайней (на данный момент) версии обычного C#
ЧТО такое "си-крестик-цэшарп-диез" — понятно, но главный вопрос — ЗАЧЕМ? C# — это хотя и развивающийся язык, но по сути своей — болото. Создана куча легаси кода, библиотек, которые менять никто не собирается. Юзать новые фичи, чтобы потом они не компилялись в "мелкомягком шарпе" — никому нафик не нужно. Тогда чего ради? Ради энтузазистов? Так они и на Немерле с радостью перейдут!
Здравствуйте, Kolesiki, Вы писали:
K>ЧТО такое "си-крестик-цэшарп-диез" — понятно, но главный вопрос — ЗАЧЕМ? C# — это хотя и развивающийся язык, но по сути своей — болото. Создана куча легаси кода, библиотек, которые менять никто не собирается. Юзать новые фичи, чтобы потом они не компилялись в "мелкомягком шарпе" — никому нафик не нужно. Тогда чего ради?
Берем готовый проект и делаем некоторые фичи с помощью метапрограммирования. В случае чего, всегда можно ценой вполне понятного количества ресурсов вернуться.
K>Ради энтузазистов? Так они и на Немерле с радостью перейдут!
Я пробовал. Есть серьезные минусы как в портировании кода на Nemerle так и в вынесении части кода в отдельные сборки. Могу расписать, хотя они достаточно очевидны.
Идея расширяемого шарпа очень хороша, но сыровата, возникает чертова туча нюансов с синтаксисом. Даже слегка жаль, что я ушел с .net.
Здравствуйте, Ziaw, Вы писали:
Z>Берем готовый проект и делаем некоторые фичи с помощью метапрограммирования. В случае чего, всегда можно ценой вполне понятного количества ресурсов вернуться.
Ага. Для самоуспокоения многим пойдет. В реальности же вряд ли кто вернется.
K>>Ради энтузазистов? Так они и на Немерле с радостью перейдут! Z>Я пробовал. Есть серьезные минусы как в портировании кода на Nemerle так и в вынесении части кода в отдельные сборки. Могу расписать, хотя они достаточно очевидны.
Тут главное даже не это. Есть огромный пласт людей которые просто не готовы переходить на новые языки. Это страшно, долго и затратно. А вот воспользоваться расширениями уже знакомого языка могли бы многие.
Так что для меня это способ привлечь сторонников.
Z>Идея расширяемого шарпа очень хороша, но сыровата, возникает чертова туча нюансов с синтаксисом.
Нитровский парсер настолько мощный, что если новая конструкция будет хоть немножко отличаться от старой, ему будет достаточно. Насегодня мы можем сделать Nemerle плагином к Cx#. По сути оно так и будет. Бдет базовый синтаксис и расширения описывающие уникальные вещи для C#, Nemerle дополнительные расширения реализующие новые фичи.
По сути Nitra дает нам возможность сделать весь процесс разработки языков — процессом добавления расширений. Любая часть языка может быть расширением. От макроса она будет отличаться лишь тем, что макрос переписывает код в код на том же языке, а просто расширение переписывает его в низкоуровневый код (MSIL и ему подобные вещи).
Z>Даже слегка жаль, что я ушел с .net.
Ну, Nitra спроектирована в расчете на сменяемые бэкнэнды. Прикрути бэкэнд для LLVM или Java и будет тебе счастье.
Кроме того Моно и .Net Core ведь никто не отменял. Ты, как я понимаю, просто на Линукса перешел, да?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kolesiki, Вы писали:
K>ЧТО такое "си-крестик-цэшарп-диез" — понятно, но главный вопрос — ЗАЧЕМ?
Есть большой пласт людей которые не хотят сменять язык полностью. Смена языка — это серьезное решение вызывающиее кучу проблем. В то время как смена компилятора не такой большой шаг. Даже чисто психологически это проще.
После того как эта смена произошла будет существенно проще освоить тот же Nemerle.
K>C# — это хотя и развивающийся язык, но по сути своей — болото.
Язык как язык. Не хуже многих. Его за последнее время не хило подтянули (лямбды, разные операторы безопасного доступа, асинки и т.п.). Как раз его развитие делает переход на Nemerle менее привлекательным. В 2006-м году C# выглядел как полное убожество по сравнению с Nemerle. Жаль только сам Nemerle был сыр, а большинство народа просто не понимали все его мощи. Сегодня же Nemerle не имеет такого отрыва, хотя, конечно, преимуществ хватает.
K>Создана куча легаси кода, библиотек, которые менять никто не собирается.
А зачем его менять? У Cx# будет обратная совместимость с C#. Код на C# можно будет просто подключить к Cx#-проекту и начать использовать в нем новые фичи.
K>Юзать новые фичи, чтобы потом они не компилялись в "мелкомягком шарпе" — никому нафик не нужно.
Гупость говоришь. Почти все пользователи C# со временем переходят на его более новые версии. Никто не жалеет о том, что C# 7 не компилируется компилятором C# 1 или 2. Cx# есть и никуда не исчезает. Он будет развиваться вместе с C# и получать все его новые фичи.
Если уж понадобится отказаться от использования Cx# и вернутся на C#, то достаточно будет просто декомпилировать полученные сборки. Можно даже написать бэкэнд генерирующий C#-проект вместо сборок.
K>Тогда чего ради? Ради энтузазистов? Так они и на Немерле с радостью перейдут!
Ну, как показывает практика люди с опаской переходят на совсем новые языки. Даже у языка от МС (F#) есть такая проблема. И у Скалы. Нужны не хилые рекламные силы чтобы протолкнуть язык в реальную жизнь.
У нас же Cx# получится за счет совсем незначительных усилий.
В Cx# есть и другие резоны. В отличии от Nemerle сам C# является специфицированным языком. Плюс к нему есть эталонная реализация и большая кодовая база. Это позволяет упростить процесс разработки и отладки фич языка. Спецификация разъясняет синтаксис и семантику, а наличие эталонной реализации позволяет проверить правильность реализации. При этом Nemerle получит точно такую же фичу (с другим синтаксисом) на халяву.
Мы сможем ссылаться на спецификацию C# и указывать только отклонения от нее. Это позволит в спецификации того же Nemerle описывать только уникальные фичи и отображение синтаксиса.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
K>>>Ради энтузазистов? Так они и на Немерле с радостью перейдут! Z>>Я пробовал. Есть серьезные минусы как в портировании кода на Nemerle так и в вынесении части кода в отдельные сборки. Могу расписать, хотя они достаточно очевидны. VD>Тут главное даже не это. Есть огромный пласт людей которые просто не готовы переходить на новые языки. Это страшно, долго и затратно.
Ну прям страшно. Причин много, вот основные:
1) Отсутствие или незрелость инструментальных средств. Автоматического форматирования кода нормального нет, анализаторов кода нет, средств рефакторинга нет, intellisense и подсветка синтаксиса на доброй половине кода не работают, время компиляции утомительно, и это только базовые пользовательские запросы.
2) Отсутствие коммьюнити. Просто некуда идти с проблемами. Нет stackoverflow. Нет обширной опенсорсной кодовой базы. Документации нормальной нет. Книг нет. Блогов нет. Роадмапа нет. За пределами RSDN Nemerle будто и не существует.
3) Ну и непонятно, какую серьезную проблему решаем этим переходом. C# уже достаточно хорош. Стимул недостаточен.
VD>А вот воспользоваться расширениями уже знакомого языка могли бы многие. VD>Так что для меня это способ привлечь сторонников.
Сторонников чего? Немерле или Нитры?
Если Нитры, то она уже прекрасна, не хватает только полировки. Если все заявленные фичи заработают, успех должен прийти. Ведь аналогов еще нет. И польза есть уже прямо сейчас, и может быть стоит на ней акцентировать, а не оттенять, создавая впечатление, что Нитра это просто шаг на пути к Cx# — очередной сомнительной (для стороннего наблюдателя) попытки обыграть конкурента на чужом поле.
Здравствуйте, VladD2, Вы писали:
VD>Тут главное даже не это. Есть огромный пласт людей которые просто не готовы переходить на новые языки. Это страшно, долго и затратно. А вот воспользоваться расширениями уже знакомого языка могли бы многие.
Дело скорее не в том, что долго или затратно, а в том, что риски сложно считать. Если я знаю цену решения неожиданной проблемы, можно считать и думать, если я ее не знаю, это все равно, что начнем писать с нуля.
VD>Нитровский парсер настолько мощный, что если новая конструкция будет хоть немножко отличаться от старой, ему будет достаточно. Насегодня мы можем сделать Nemerle плагином к Cx#. По сути оно так и будет. Бдет базовый синтаксис и расширения описывающие уникальные вещи для C#, Nemerle дополнительные расширения реализующие новые фичи.
Проблема не в распарсить, а в грамотном расширении и генерации кода. Например мне кажется, что квазицитирование для шарпа не будет таким красивым из-за отсутствия принципа "все есть выражение". И с матчингом по цитатам будет сложно. Но это пока только интуиция, для примеров надо начать погружаться в проблему.
VD>По сути Nitra дает нам возможность сделать весь процесс разработки языков — процессом добавления расширений. Любая часть языка может быть расширением. От макроса она будет отличаться лишь тем, что макрос переписывает код в код на том же языке, а просто расширение переписывает его в низкоуровневый код (MSIL и ему подобные вещи).
VD>Кроме того Моно и .Net Core ведь никто не отменял. Ты, как я понимаю, просто на Линукса перешел, да?
У меня сейчас большой и долгоиграющий проект (не на один год). В основном ruby.
Здравствуйте, Ziaw, Вы писали:
Z>Проблема не в распарсить, а в грамотном расширении и генерации кода. Например мне кажется, что квазицитирование для шарпа не будет таким красивым из-за отсутствия принципа "все есть выражение". И с матчингом по цитатам будет сложно. Но это пока только интуиция, для примеров надо начать погружаться в проблему.
тоже самое как умножение убивает суперкомпиляцию или числа плавающий запятой.
Здравствуйте, Ziaw, Вы писали:
Z>Проблема не в распарсить, а в грамотном расширении и генерации кода. Например мне кажется, что квазицитирование для шарпа не будет таким красивым из-за отсутствия принципа "все есть выражение".
Квази-цитирование делается для любого языка. Тут скорее проблема в том, что в Немерле были некоторые умолчания позволяющие сделать цитаты проще. Из-за этого были и проблемы. Грубо говоря на квази-цитирование можно смотреть как на продвинутые интерполированные строкуи. Ты ведь строками любой код сможешь сгенерировать? Значит, потенциально, и квази-цитаты можно сделать для чего угодно.
У нас уже был опыт генерации квази-цитат для любого языка и этот код даже остался. Проблемы там возникало две:
1. Для этого мы генерировал отдельный парсер. Это означало, что перед применением его надо было скомпилировать. А это значит, что мы не можем применить цитаты внутри самого компилятора.
2. В общем случае сплайсы имеют разные типы. И в общем случае невозможно идентифицировать вместо какого подрправила должен использоваться сплайс. Чтобы устранить неоднозначность, приходится в сплайсы вставлять информацию о подправиле которая заменяет эта цитата. Вот пример паттерна для C#-а:
quote match (ast)
{
| <# TypeMemberDeclaration: $Attributes(_) $Modifiers(_)
const string $Name(name) = $ConstantExpression(str is Expression.RegularStringLiteral); #> =>
Здесь TypeMemberDeclaration — это имя правила которое надо матчить, а Attributes, Modifiers, ConstantExpression имена подправил к которым пренадлежат сплайсы. Алогичный паттерн на Немерле выглядел бы так:
Здравствуйте, VladD2, Вы писали:
VD>Квази-цитирование делается для любого языка. Тут скорее проблема в том, что в Немерле были некоторые умолчания позволяющие сделать цитаты проще. Из-за этого были и проблемы. Грубо говоря на квази-цитирование можно смотреть как на продвинутые интерполированные строкуи. Ты ведь строками любой код сможешь сгенерировать? Значит, потенциально, и квази-цитаты можно сделать для чего угодно.
Можно-то можно, но в Nemerle они легко вкладывались друг в друга, как матрешки. Они были выражениями. Как с этим будет в Cx#? Не придется ли городить костыли с типизацией списка цитат, например?
VD>Да какая разница то? Быб бы паттерн-матчинг.
Добавить его в Cx# та еще задачка.
VD>А Руби — это требование заказчика? Ты не можешь выбирать язык?
Я его сам и выбрал, это был оптимальный путь сделать нужный объем, в нужные сроки. Чтобы не разводить холивар, сразу скажу, что мы уложились, а в случае java/asp.net пролетели бы по срокам. Как поведет себя проект на поддержке/доработках время покажет. Пока полет нормальный.
Здравствуйте, Ziaw, Вы писали:
Z>Можно-то можно, но в Nemerle они легко вкладывались друг в друга, как матрешки. Они были выражениями. Как с этим будет в Cx#?
А нет никакой связи между "Они были выражениями." и "они легко вкладывались друг в друга". AST и Parse Tree — это по определению деревья. Раз они деревья, то могут вкладываться друг в друга. Паттерн — это не более чем выражение в более удобном синтаксисе того самого дерева.
Z>Не придется ли городить костыли с типизацией списка цитат, например?
Дык связи то тут нет. Типизация она нужна не для вкладывания. Она нужна для того чтобы понять чему соответсвтует сплайс.
Вот смотри. Имеем мы граматику:
syntax X = A? B? Identifier;
syntax Y = A? B? C? Identifier;
Теперь хотим ее в паттерне выразить. Пишем мы так:
match (ast)
{
| <[ $(b) test ]> => foo(b);
Какие проблемы тут будут у компилятора паттерна?
1. Он не может понять какое из правил надо разбирать. У него есть два вполне подходящих правила X и Y. Но выбрать одно из них он не может.
2. Он не может понять к чему относится цитата "$(b)". Ведь подправила "A?", "B?" и "C?" необязательные и значит они все могут подходить.
Если добавить типизацию и иногда можно вывести тип паттерна автоматически. Предположим, что тип функции foo это "option[C] -> void". Тогда нам подойдет только правило Y, так как только у него есть опциональное подправило "C". А если тип "$(b)" — это option[B], то неоднозначность остается. Ну, а если мы не может использовать типизацию для вывода типа сплайсов, то уточнения уже понадобятся не только для типа АСТа, но и для каждого сплайса.
Нам нужен способ задать конкретное правило. Это можно сделать так:
match (ast)
{
| <[ X: $(b) test ]> => foo(b);
Здесь "X:" указывает компилятору, что паттерн должен разбирать правило "X" нашей грамматики.
А сплайс можно уточнить так:
match (ast)
{
| <[ X: $A(b) test ]> => foo(b);
И вот уже компилятор точно знает что мы от него хотим.
Z>Добавить его в Cx# та еще задачка.
Да в общем не сложнее чем в Nemerle. Кое какую теорию надо знать. Но вот Хардкейс уже делал поддержку ПМ для Нитры. Так что и для Шарпа сделаем.
Z>Я его сам и выбрал, это был оптимальный путь сделать нужный объем, в нужные сроки. Чтобы не разводить холивар, сразу скажу, что мы уложились, а в случае java/asp.net пролетели бы по срокам. Как поведет себя проект на поддержке/доработках время покажет. Пока полет нормальный.
Ну, тогда у тебя не будет проблем и другую технологию взять, если она позволит задачи решать быстрее или легче.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Какие проблемы тут будут у компилятора паттерна? VD>1. Он не может понять какое из правил надо разбирать. У него есть два вполне подходящих правила X и Y. Но выбрать одно из них он не может. VD>2. Он не может понять к чему относится цитата "$(b)". Ведь подправила "A?", "B?" и "C?" необязательные и значит они все могут подходить.
VD>Здесь "X:" указывает компилятору, что паттерн должен разбирать правило "X" нашей грамматики.
Да, я как раз про это. Если для Nemerle был минимальный набор таких костылей, то для шарпа их должно получиться немало. И квазицитаты могут перестать заметно отличаться от вызова конструктора нужного выражения.
Здравствуйте, Ziaw, Вы писали:
Z>Да, я как раз про это. Если для Nemerle был минимальный набор таких костылей, то для шарпа их должно получиться немало. И квазицитаты могут перестать заметно отличаться от вызова конструктора нужного выражения.
Дело не в шарпе. В этом плане Шарп от немерла не сильно отличается. Дело в универсальности решения. В Немерле оно было не универсальное. И разбирать было далеко не все конструкции можно, и при разборе ограничения были.
Это проблемы обобщенного решения. А если захордкодить все как в Немерле, то добиться примерно того же самого.
В немерле на разные кривых костыли шли для упрощения. И потом они сильно мешали людям. Например, идентификаторы и атрибуты у типов было не так-то просто разобрать. Я сам с этим по началу сильно мучился. Чтобы разобрать идентификаторы и атрибуты надо было писать не
$custom_attrs $modifiers class $(name : name)
{
}
А:
..$мутная_структура_с_кривым_именем class $(name : name)
{
}
Причем мутная_структура_с_кривым_именем это ни разу не списко получался (как в остальных случаях), а именно специальный тип, который в то время еще и совершенно не внятное название имел.
Короче, народ путался с этими костылями постоянно. Все это очень сложно получалось.
Универсальное решение хотя и многословные получилось, но куда более интуитивно понятным.
У авторов Немерла еще одна идея была — скрыть от пользователей сам факт наличия АСТ-а. Мол не надо людям имена узлов АСТ-а знать. Но по факту запутали только больше, а люди все равно были вынуждены с типами возиться.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
По сути оно так и будет. Бдет базовый синтаксис и расширения описывающие уникальные вещи для C#, Nemerle дополнительные расширения реализующие новые фичи.
