Приветствую всех.

Мы подошли к моменту когда на Nitra можно создать компиляторы (и, естественно, IDE-интеграцию) для расширяемого C# и Nemerle 2.0.

Точнее создать компиляторы можно для чего угодно, но особо хочется создать их именно для C# и новой версии Nemerle.

Работа предстоит не маленькая, так что хочется найти сподвижников в этом не легком деле.

Уверен, что в Nitra придется многое усовершенствовать, так что мы (разработчики ядра Nitra) видимо будем вынуждены уделять много времени именно Nitra. По сему нужны добровольцы которые будут писать код для Nemerle 2.0 и расширяемого C#.

Требования к добровольцам простые:
1. Опыт разработки по дотнет.
2. Знание (желание изучить) Nemerle 1.х.
3. Знание C#.
4. Желание изучить Nitra.
5. Пламенный мотор вместо сердца.

Какие задачи нужно решить...
По Nitra-C#:
1. Написать типизацию для выражений C#.
2. Написать часть .Net-бэкэнда отвечающую за генерацию кода и запись метаданных в дотнетные сборки.

По Nemerle 2.0 задача по сложнее, так как нужно еще написать парсер Nemerle на Nitra, типизацию для таких не простых выражений как паттерн-матчинг и воспроизвести базовые макросы Nitra 1.х в формате синтаксических расширений Nitra. В прочем, синтаксис верхнего уровня у Nemerle очень похож на шарповскский, так что можно будет использовать его за основу.

В принципе мы можем сделать даже один единый компилятор который будет понимать и синтаксис C#, и синтаксис Nemerle в одном файле. Но не уверен, что это хороший подход. Возможно достаточно будет иметь возможность содержать в одном проекте одновременно файлы Nemerle и Nitra-C# (это довольно просто).

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

В дальнейшем, если кому интересно, можно занятием создания бэкэнов позволяющих компилировать код под другие платформы (Java, LLVM). Реализовав бэкнды под эти платформы мы сможем автоматически портировать на них Nitra, C#, Nemerle и другие языки использующие символы дотнета.

Если кто-то хочет поучаствовать в этих проектах, пишите в ответ на это сообщение.

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

VD>Если кто-то хочет поучаствовать в этих проектах, пишите в ответ на это сообщение.

Поучаствовать хочется, но есть сомнения реально ли это потянуть, так как нет знаний
1. предметной области (компиляторостроение)
2. самой nitra

Кроме того, C# — это очень сложный комплексный язык, где одна только спецификация пятой версии занимает более 500 страниц.
Я сомневаюсь, что сейчас можно зайти со стороны, то есть не будучи автором nitra, и начать приносить реальную пользу.

Может, стоит перед тем, как звать людей делать C# и тем более Nemerle 2, нарисовать что-то попроще, чтобы было ясно, по пунктам, как делаются языки с применением nitra? Может, потенциальным участникам стоит сделать с вашей помощью что-то подобное? Это не должно занять много времени, но перспективы участия в разработке C# должны сильно проясниться, я полагаю.

Потом хочется какого-то понимания, как будет устроен процесс работы.
Как будут ставится задачи, кто все это запроектирует, как будет тестироваться, когда и в каком формате будет проходить общение. Опыт этого раздела, например, показывает, что общение выходит достаточно рваным, так как какие-то вполне конкретные предментные вопросы могут оставаться без внимания долгое время.

VD>Со своей стороны мы будем помогать и обучать.

Этого явно недостаточно, я считаю. Если говорить за себя, то не знаю досконально спецификацию C#, читаю IL-код не без проблем и ориентируюсь там в основном по комментариям из-чего он был сгенерирован. То есть даже часть генерации IL, которая не является чем-то nitra-специфичным, выглядит для меня сложно.

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

И, наконец, в gitter-конференции (где по какой-то причине нет никого из ведущих разработчиков языка) обсуждался вопрос целесообразности воспроизведения Nemerle на nitra в его текущем виде. Вот только несколько тем:
— option как значимый тип и его поддержка в компиляторе
— non-nullable types
— методы расширения в стиле F# (обсуждалась поддержка свойств и расширения для статических классов)
— захардкоженные конвенции (невозможно называть типы с маленькой буквы, например)
И далее в таком духе. Это как дискуссия про nemerle base-level, только вместо фатального неприятия C#-программистами when вместо if, обсуждались чуть другие вещи.

Я понимаю, что перспективы Nemerle 2 еще более туманны, чем воспроизведенного на nitra C#, но есть ощущение, что именно это и привлекает внимание людей. У C# сейчас всё хорошо — есть кроссплатформенный roslyn, core clr, ahead of time компиляция в нативный код и тд. И лично меня не сильно интересует воспроизведение C# со всеми его недостатками, которые тянуться со времен первой версии. Полагаю, что я не один такой.

Это вопрос мотивации, потому как люди понимают, что сейчас какие-то вещи сделаны в C# или F# более оптимально чем в Nemerle. А есть еще и опыт других языков. И нужно, во-первых, понимание, какие задачи стоят в разработке Nemerle 2 (nitra в качестве подсистемы макросов здорово, но либо хочется еще профитов, либо нет понимания, к чему это ведет), во-вторых, открытая дискуссия по этим задачам. Было предложение создавать issue с proposal'ами в репозитории текущего Nemerle, но, имхо, это писать в никуда.

Резюмирую:
— надо потренироваться на кошках, перед тем как браться за C#
— надо определить архитектор(а/ов) / ведущещ(его/их) разработчик(а/ов)
— надо напилить маленьких понятных задач
— надо обсуждать перспективы языка, которому посвящен раздел

Это не требования, но без этого что-то поднять будет сложно, на мой взгляд. Потому как я, использующий в Nemerle в продакшене разработчик, на текущий момент более заинтересован в улучшении качества инфраструктуры и компилятора текущего Nemerle, чем в трате времени создание кальки на C# или тот же самый текущий Nemerle. Никто ведь не объяснил внятно, зачем и кому нужен расширяемый C# на nitra и переписанный Nemerle.

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

VD>По сему нужны добровольцы которые будут писать код для Nemerle 2.0

Насколько реально сделать макро-ядро Nemerle 2.0 независимым от системы типов .NET?
Например чтобы на той же базе можно было сделать язык с более продвинутой системой типов, изначально нацеленный на native/LLVM?
В идеале конечно хотелось бы иметь какую-нибудь совместимость между макро библиотеками (то есть из макро-ядра вырастить разные языки, но чтобы была возможность переиспользовать схожие макросы между языками).

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

EP>Насколько реально сделать макро-ядро Nemerle 2.0 независимым от системы типов .NET?
Nemerle 2.0 это язык под .НЕТ.
Макро ядро Nemerle 2.0 называется Nitra.
Nitra самостоятельный продукт и изначально проектировался как инструмент для создания любых языков под любые платформы.

EP>Например чтобы на той же базе можно было сделать язык с более продвинутой системой типов, изначально нацеленный на native/LLVM?
Немерле нет. Нитра да.

EP>В идеале конечно хотелось бы иметь какую-нибудь совместимость между макро библиотеками (то есть из макро-ядра вырастить разные языки, но чтобы была возможность переиспользовать схожие макросы между языками).
Для высокоуровневых ДСЛ такое вполне возможно.

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

EP>Насколько реально сделать макро-ядро Nemerle 2.0 независимым от системы типов .NET?

Независимое от системы типов почти не реально, так как от какой-то системы типов язык должен зависеть. И если он зависит от другой системы типов, то он становится другим языком. Система типов она ведь задает основные возможности языка.

Но важно понимать, что рантайм дотнета и система типов дотнета — это соврешенно разные вещи. Систему типов дотнета можно воспроизвести и на базе Ява-машины (хотя там будут трудности с вэйлью-типами), и даже на базе нэйтива/LLVM. Можно даже сделать вариант Немерла без ЖЦ, но при этом нужно подумать о том как в таком языке управлять памятью. Например, можно создать вариант с подсчетом ссылок. Но, при этом, нужно понимать, что написание кода на таком языке будет несколько отличаться. И программы не будет полностью совместимы с немерлом для управляемых сред.

EP>Например чтобы на той же базе можно было сделать язык с более продвинутой системой типов, изначально нацеленный на native/LLVM?

А что ты понимаешь под "более продвинутой системой типов"? Если под этим понимается поддержка шаблонов аля С++-шаблоны, то это сделать можно. Но система типов Дотнета очень даже продвинутая. Гибкость системы типов дотнета во многом завязана на использование ЖЦ. Для меня язык с ручным управлением памятью имеет менее продвинутую систему типов, например.

EP>В идеале конечно хотелось бы иметь какую-нибудь совместимость между макро библиотеками (то есть из макро-ядра вырастить разные языки, но чтобы была возможность переиспользовать схожие макросы между языками).

Для начала хочется услышать четкую постановку задачи. Что мы хотим сделать? Попробую простить задачу приведя возможные варианты. И так мы можем хотеть получить:
1. Язык похожий на Немерл, но исполняемые модули которого будут нативными или LLVM-ыми. Тут основная проблема — это поддержка ЖЦ. Если ее реализовать, или ограничиться, например, подсчетом ссылок (ЖЦ для бедных), то создать такой язык можно и это относительно не сложно. Создание же и поддержка в языке ЖЦ для нэтива — это довольно сложная задача. Плюс ко всему в этом не так много смысла, так как уже есть компиляторы с дотнет-сборок в нэйтив код.

2. Мы хотим расширить систему типов Немерла теми или иными фичами, например, шаблонами похожими на С++-ные. Это сделать довольно просто.

3. Нечто среднее между пунктами 1 и 2 — язык компилируемый в нэйтив и имеющий расширенную систему типов.

Макросы — это не более чем плагины к компилятору которые реинтерптируют некоторый синтаксис языка (меняют семантику) или вводят новый. В итоге макрос должен порождать какой-то код. Но если даже у языка, реализованного под разные платформы, идентичный синтаксис — это еще не значит, что одинаковый код будет работать для обоих платформ. Макрос рассчитанный на нйэтив без поддержки ЖЦ не сможет использовать некоторые фичи доступные для управляемого варианта языка. В обратную сторону поддержать совместимость проще, но тоже можно нарваться на грабли.

Короче, можно все. Вопрос в стоимости решения и в геморрое который будет возникать при использовании кода под разные платформы.

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

EP>Не только IDE, но и как я понял можно автоматом получить лёгкую расширяемость и макросы.

Само собой.

EP>Я же не просто про какой-то левый язык на базе Nitra спросил, а конкретно про возможность разделения части кодовой базы этого языка с Nemerle 2.0. Думаю возможность такого разделения-переиспользования должна быть как-то заранее учтена при разработке Nemerle 2.0 — и этот момент полностью относится к этой данной теме, IMO.

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

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

В любом случае тут есть что обсудить с народом. Например, что брать из С++? Очевидно, что С-шный препроцессор — это зло и его брать не следует. А вот нужно ли брать из С++ шаблоны со всеми сложностями и проблемами — это большой вопрос. Мне кажется, что полные по тюрингу шаблоны в языке с макросами не нужны.

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

J>Это разве что макросы высшего порядка (т.е. зовущие другие макросы) можно сделать кросс-языковыми, а первичные макросы — имхо, никак.

Если макросы (или нечто их заменяющее) будут работать на уровне АСТ-а дотнета, то их можно будет применять для любого языка основанного на этом АСТ-е.

Синтакси, естественно, придется написать свой для каждого языка. А вот реализацию можно будет иметь общую для группы языков. Так что Nemerle 2.0 и C# могут иметь общие макросы.

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

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

VD>>По сему нужны добровольцы которые будут писать код для Nemerle 2.0

EP>Насколько реально сделать макро-ядро Nemerle 2.0 независимым от системы типов .NET?
EP>Например чтобы на той же базе можно было сделать язык с более продвинутой системой типов, изначально нацеленный на native/LLVM?
EP>В идеале конечно хотелось бы иметь какую-нибудь совместимость между макро библиотеками (то есть из макро-ядра вырастить разные языки, но чтобы была возможность переиспользовать схожие макросы между языками).

Как ты себе это представляешь?
Вот, допустим, есть макрос, реализующий SQL. Написанный для Nemerle. Как ты его заюзаешь в С++, ведь у макроса внутри немерлевые потроха?
Это разве что макросы высшего порядка (т.е. зовущие другие макросы) можно сделать кросс-языковыми, а первичные макросы — имхо, никак.

You will always get what you always got
  If you always do  what you always did

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

VD>Но важно понимать, что рантайм дотнета и система типов дотнета — это соврешенно разные вещи. Систему типов дотнета можно воспроизвести и на базе Ява-машины (хотя там будут трудности с вэйлью-типами), и даже на базе нэйтива/LLVM.

Да, это понятно.

EP>>Например чтобы на той же базе можно было сделать язык с более продвинутой системой типов, изначально нацеленный на native/LLVM?
VD>А что ты понимаешь под "более продвинутой системой типов"? Если под этим понимается поддержка шаблонов аля С++-шаблоны, то это сделать можно.

Да, C++/D шаблоны. Близкое по духу — специализации/вариадики/и т.п., но необязательно калька.

VD>Но система типов Дотнета очень даже продвинутая.

Куча ограничений, например у структур. Или как например сделать элементарный АТД variant?

VD>Гибкость системы типов дотнета во многом завязана на использование ЖЦ. Для меня язык с ручным управлением памятью имеет менее продвинутую систему типов, например.

Ручное/автоматическое управление памятью практически ортогонально системе типов, это скорее рантайм, ИМХО. В C++ есть API для GC, а в том же D GC есть "искаропки".
Тут разве что RAII стоит особняком, который можно отнести к системе типов.

EP>>В идеале конечно хотелось бы иметь какую-нибудь совместимость между макро библиотеками (то есть из макро-ядра вырастить разные языки, но чтобы была возможность переиспользовать схожие макросы между языками).
VD>Для начала хочется услышать четкую постановку задачи. Что мы хотим сделать?

В порядке убывания приоритета:
1) полноценную замену C++ с такими же основополагающими принципами — zero-overhead и т.п.
2) продвинутую систему типов (как я понял макросами не особо получится исправить недостатки системы типов, поэтому лучше сразу заложить качественную основу)
3) библиотечные синтаксические расширения, гигиеничные макросы а-ля Nemerle, расширенные возможности в compile-time
4) современный лаконичный синтаксис без груза исторических проблем
5) при всём при этом хотелось бы не повторять ту работу, которую проведут при создании Nemerle 2.0, то есть по возможности переиспользовать готовый код

VD>Попробую простить задачу приведя возможные варианты. И так мы можем хотеть получить:
VD>1. Язык похожий на Немерл, но исполняемые модули которого будут нативными или LLVM-ыми.

Не вижу в этом особого смысла — ведь без разницы будет там .NET runtime или какой-нибудь другой, разве что будет возможность исправить те места, за которые Microsoft не берётся в плане кодогенерации.

VD>Макросы — это не более чем плагины к компилятору которые реинтерптируют некоторый синтаксис языка (меняют семантику) или вводят новый. В итоге макрос должен порождать какой-то код. Но если даже у языка, реализованного под разные платформы, идентичный синтаксис — это еще не значит, что одинаковый код будет работать для обоих платформ. Макрос рассчитанный на нйэтив без поддержки ЖЦ не сможет использовать некоторые фичи доступные для управляемого варианта языка. В обратную сторону поддержать совместимость проще, но тоже можно нарваться на грабли.

Да, это понятно. Выше уже подсказали пример где макросы легко переиспользовать в разных языках — макросы высшего порядка.

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

s22>Лучше бак энд для джаваскрипт....

Такое есть и для Nemerle 1.0. Он находится в составе проекта NemerleWeb. Естественно, что сделать аналог для Nemerle 2.0 будет так же можно. Скажу больше бэкэнд делается для АСТ в который может преобразовываться не только Nemerle 2.0, но и любой другой язык для дотнета сделанный на Nitra. Так что, например, C# тоже можно будет преобразовывать в JavaScript, если такой бэкэнд сделать.

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

VD>>Не, но на нас они их тратить нетхотят. Они их на Котлин, например, тратят.

W>Получается что проект мертворожденный и не нужный.

Это какая-то извращенная логика. То что кто-то считает один проект перспективнее другого, не означает, что второй проект не перспективный. Время рассудит.

W>Зачем тогда кому-то тратить время бесплатно пилить ваше поделие? Какая-то мотивация кроме саморазвития присутствует?
W>Для саморазвития разрабу можно найти проекты с куда большим visibility для своего резюме.

Да хоть в крестики нолики играй для саморазвития и резюме. Нам резюмисты/карьеристы не нужны. Нам нужны люди способные делать сложные вещи и способные самостоятельно оценивать перспективность.

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

VD>2. Написать часть .Net-бэкэнда отвечающую за генерацию кода и запись метаданных в дотнетные сборки.

Фига себе, вы это до сих пор не сделали? А чтение метаданных у вас есть?

Может глянете тогда как и что в Рослине сделано, там код вроде бы открытый.

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

VD>По Nemerle 2.0 задача по сложнее, так как нужно еще написать парсер Nemerle на Nitra, типизацию для таких не простых выражений как паттерн-матчинг и воспроизвести базовые макросы Nitra 1.х в формате синтаксических расширений Nitra. В прочем, синтаксис верхнего уровня у Nemerle очень похож на шарповскский, так что можно будет использовать его за основу.

Желание есть, но в ближайшие недели три буду довольно плотно занят, позже станет полегче, но все равно слишком много времени не будет (семья и все такое). Добавь меня пока на всякий случай в список, хотя бы не придется в случае чего вводить в курс дела.

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

VD>>2. Написать часть .Net-бэкэнда отвечающую за генерацию кода и запись метаданных в дотнетные сборки.

IT>Фига себе, вы это до сих пор не сделали?

Сама Нитра пока что использует Немерл 1.х.

IT>А чтение метаданных у вас есть?

Да. Именно это в бэкнде, пока, и есть.

IT>Может глянете тогда как и что в Рослине сделано, там код вроде бы открытый.

Естественно, что мы на это "глянули". Причем очень давно. Там копипаста CCI Metadata. Причем ее типы тупо сделали internal, а сборкам шарпа и васки сделали "дружесвенный" доступ.

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

VD>Мы подошли к моменту когда на Nitra можно создать компиляторы

Т.е. все фазы завершены?

VD>Работа предстоит не маленькая, так что хочется найти сподвижников в этом не легком деле.

Влад, не совсем понятно, почему ты их ищешь, когда есть целый тырнет "опенсорсников". Или "сподвижник" будет работать над закрытым кодом? Тогда неясно вот это:

VD>5. Пламенный мотор вместо сердца.

Думал, тут будет "вместо зарплаты".

VD>По Nemerle 2.0 задача по сложнее

Т.е. сам Немерле-2 уже существует в спеках??

Влад, я думаю, что наиболее простой и быстрый план — это вам самим начать реализовывать Немерлю-2 на Нитре (т.е. составить некий скелет с ощутимым покрытием разных фич), а потом уже кто-то будет постепенно въезжать и развивать его — где-то по аналогии, где-то своим умом. Потому что вот так с нуля, по зашоренной деталями документации, навряд ли кто-то сразу въедет в тему. Да и Нитра — никто её не знает лучше создателей. А затем можно составить подробнейший список задач и пусть опенсорс потихоньку берёт подзадачи расширяет компилер.

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

IT>>Может глянете тогда как и что в Рослине сделано, там код вроде бы открытый.
VD>Естественно, что мы на это "глянули". Причем очень давно. Там копипаста CCI Metadata. Причем ее типы тупо сделали internal, а сборкам шарпа и васки сделали "дружесвенный" доступ.

Ну так по аналогии, копипаста, интернал...

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

IT>Ну так по аналогии, копипаста, интернал...

А смысл? Есть базовый CCI в виде библиотеки. В Core CLR, вот, нашли фатальный недостаток во всех остальных решениях и другого его устраняют. Как устранят, скорее всего Розлин переведут на Core CLR-ное решение (которое к тому времени станет стандартом). Вот на него имеет смысл переходить.

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

VD>В дальнейшем, если кому интересно, можно занятием создания бэкэнов позволяющих компилировать код под другие платформы (Java, LLVM). Реализовав бэкнды под эти платформы мы сможем автоматически портировать на них Nitra, C#, Nemerle и другие языки использующие символы дотнета.

Лучше бак энд для джаваскрипт....

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

EP>>В идеале конечно хотелось бы иметь какую-нибудь совместимость между макро библиотеками (то есть из макро-ядра вырастить разные языки, но чтобы была возможность переиспользовать схожие макросы между языками).
J>Как ты себе это представляешь?
J>Вот, допустим, есть макрос, реализующий SQL. Написанный для Nemerle. Как ты его заюзаешь в С++, ведь у макроса внутри немерлевые потроха?
J>Это разве что макросы высшего порядка (т.е. зовущие другие макросы) можно сделать кросс-языковыми, а первичные макросы — имхо, никак.

Да, естественно только часть обобщённых макросов, не завязанных на различия в типах целевых языков (либо специально отвязанных абстракциями от этих различий).

Я хочу помочь в разработке nemerle и/или nitra.
Берите меня. Мне нравится nemerle, только я его не знаю, но готов изучать, пламенный мотор вместо сердца присутствует, можете не сомневаться.

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

WH>Nemerle 2.0 это язык под .НЕТ.

Уточню. Nemerle — это язык проектировавшийся под .Net. Но в принципе его (как и любой другой язык дотнета) можно портировать на другие платформы, если написать для них бэкэнд поддерживающий сериализацию и десериализацию метаданных и кода, а так же реализовать рантайм необходимый для работы языка (о библиотеках скромно умолчим).

Так что в принципе, Nemerle 2.0 можно портировать и под другие платформы.

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

EP>Да, C++/D шаблоны. Близкое по духу — специализации/вариадики/и т.п., но необязательно калька.

Шаблоны можно навернуть как расширение к языкам базирующимся дотнетной системе типов (еще раз подчеркиваю, что система типов != целевая платформа).

EP>Куча ограничений, например у структур. Или как например сделать элементарный АТД variant?

Как в немерле — сделать объектом.

EP>Ручное/автоматическое управление памятью практически ортогонально системе типов, это скорее рантайм, ИМХО. В C++ есть API для GC, а в том же D GC есть "искаропки".

Не совсем так. Влияние есть. Те же ограничения вэлью-типов — это как раз и есть влияние ЖЦ на систему типов. Невозможность получить ссылку на объект в стеке — тоже.

EP>Тут разве что RAII стоит особняком, который можно отнести к системе типов.

В каком-то смысле — да. Это паттерн рожден под давлением ограничений системы типов С++.

EP>В порядке убывания приоритета:
EP>1) полноценную замену C++ с такими же основополагающими принципами — zero-overhead и т.п.
EP>2) продвинутую систему типов (как я понял макросами не особо получится исправить недостатки системы типов, поэтому лучше сразу заложить качественную основу)

Система типов — основополагающая вещь. Она закладывает очень многие преимущества и недостатки. Вопрос лишь в интерпретации. Для меня вот ручное управление — недостаток. Для тебя, похоже, достоинство.

На остальное позже отвечу.

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

EP>>Да, C++/D шаблоны. Близкое по духу — специализации/вариадики/и т.п., но необязательно калька.
VD>Шаблоны можно навернуть как расширение к языкам базирующимся дотнетной системе типов

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

EP>>Куча ограничений, например у структур. Или как например сделать элементарный АТД variant?
VD>Как в немерле — сделать объектом.

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

EP>>Ручное/автоматическое управление памятью практически ортогонально системе типов, это скорее рантайм, ИМХО. В C++ есть API для GC, а в том же D GC есть "искаропки".
VD>Не совсем так. Влияние есть.

Какое-то есть, да, поэтому я и написал "практически".

EP>>Тут разве что RAII стоит особняком, который можно отнести к системе типов.
VD>В каком-то смысле — да. Это паттерн рожден под давлением ограничений системы типов С++.

Этот паттерн рождён из необходимости scope-based управления ресурсами при летающих исключениях. Что характерно, присутствует во всех mainstream языках, пусть и в обрезанной форме.

EP>>В порядке убывания приоритета:
EP>>1) полноценную замену C++ с такими же основополагающими принципами — zero-overhead и т.п.
EP>>2) продвинутую систему типов (как я понял макросами не особо получится исправить недостатки системы типов, поэтому лучше сразу заложить качественную основу)
VD>Система типов — основополагающая вещь.

О том и речь, и макросами в ней можно закрыть далеко не все дыры, по-крайней мере малой кровью.

VD>Она закладывает очень многие преимущества и недостатки. Вопрос лишь в интерпретации. Для меня вот ручное управление — недостаток. Для тебя, похоже, достоинство.

При прочих сферических равных, чем более всё автоматизированно, тем естественно лучше — само по себе ручное управление достоинством не является. Вот только нет этих сферических равных.
И речь же не про ручное/автоматическое, а конкретно про GC vs scoped-based. Да и "ручным" управлением называть scope-based неверно. Да, есть выбор из ряда вариантов, в том числе даже и GC. Но если наличие выбора называть ручным управлением, тогда и в .NET оно ручное — так как например имеется выбор между struct/class.

Так вам еще помощники нужны?

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

VD>>Шаблоны можно навернуть как расширение к языкам базирующимся дотнетной системе типов

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

Зачем говорить ерунду? С прекручиванием шаблонов к донтентной системе типов никаких теоретических проблем нет. Они даже самому дотнету будут по фиг (опять же напоминаю, что дотнетная система типов и сам дотнет — это разные вещи). Они во время компиляции раскрываются.

EP>Насколько я вижу: со стороны системы типов нет гарантии что варианты состоящие из одинакового списка типов будут иметь один и тот же тип, нет гарантии закрытости.

В Нитре систему типов делаешь/изменяешь ты сам. Что сделаешь, то и будет. Конечно, если сгенерировать дотнетную сборку и заюзать типы из не нитровского языка, то они будут видны как обычные классы. Но в нитровском языке ты будешь иметь дело с тем типом, что опишешь. Так что если тебе нужно сделать чтобы иерархию нельзя было расширить — не проблема, сделай.

Кроме того варианты с возможностью расширения так же востребованы на практике. Например, мы в Нитре были вынуждены делать открытые иерархии, так как Нитра подразумевает расширяемость в любом месте.

EP>Какое-то есть, да, поэтому я и написал "практически".

Ну, да. В русском языке "практически — да" означает "теоретически, но на практике нет" или "не совсем возможна".

EP>Этот паттерн рождён из необходимости scope-based управления ресурсами при летающих исключениях. Что характерно, присутствует во всех mainstream языках, пусть и в обрезанной форме.

Мы говорим о С++-ном термине? Если — да, то в С++ речь идет о наличии конструкторов и деструкторов у объектов вызываемых при выходе из области видимости. И в С++ это дело используется для автоматизации управления памятью. Результат — море багов связанное с этим дело и ряд проблем иделогического порядка (например, проблемы с исключениями в деструкторах/конструкторах).

Ладно. Это вопрос филосовфский. К делу не относится. С++-ый вариант сделать намного проще. Но если бы я был пользователем языка, я бы пожелал наличие хоть какой-то автоматизации управления память. Хотя бы автоматический подсчет ссылок.

EP>О том и речь, и макросами в ней можно закрыть далеко не все дыры, по-крайней мере малой кровью.

Ну, то что в С++ делается с помощью метапрограммирования на шаблонах почти на 100 можно заменить макрами. В 90% случаев они удобнее, быстрее и понятнее будут.

Что касается свойств шаблонов, то да. Такие их свойства как:
1. Раскрытие во время компиляции.
2. Переменное число аргументов.
3. Утиная типизации (вытекает из п. 1).

Делаю их более мощными, хотя и порождают некоторые недостатки.

Вообще, то что шаблоны раскрываются во время компиляции роднит их с макросами. По сути и то, и то является средствами метапрограммирования времени компиляции. Но шаблоны идут от системы типов, а макросы от языка.

EP>При прочих сферических равных, чем более всё автоматизированно, тем естественно лучше — само по себе ручное управление достоинством не является. Вот только нет этих сферических равных.

+1

EP>И речь же не про ручное/автоматическое, а конкретно про GC vs scoped-based. Да и "ручным" управлением называть scope-based неверно.

Верно. Ручное оно не от того, что "scope-based", а от того, что нужно проделывать ряд приседаний для его работы и при этом можно легко ошибиться.

Но проблема подхода принятого в С++ не только в том, что оно там ручное. Проблема еще и в том, что есть куча возможностей языка позволяющих легко нарушить инварианты этих, реализованных в ручную, правил управления памятью. Например, можно выделить память в стеке и передать ее куда-то где указатель на нее положат в поле другого объекта. И это никак не проконтролируешь. Вот в Расте попытались эту проблему решить, но при этом сам язык превратили в далекий от менэстрима.

EP>Да, есть выбор из ряда вариантов, в том числе даже и GC. Но если наличие выбора называть ручным управлением, тогда и в .NET оно ручное — так как например имеется выбор между struct/class.

Выбор между struct/class — это выбор стратегии. Сама стратегия реализуется автоматически. Естественно — это и ограничение. Манипулировать памятью становит я сложнее, что снижает потенциал оптимизаций.

ЗЫ

Мы ушли не в ту степь. Мы начали дискутировать о принципах управления памятью и о системах типов.

Данная тема вообще посвящена конкретным языкам. В них эти вопросы определены.

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

Если хочешь обсудить этот другой язык, то лучше создай отдельную тему. Можно даже не тут, а в Философии программирования. Там к нему присоединиться много народа. Мне есть что высказать по этому вопросу, но эта тема немного о другом.

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

VD>ЗЫ
VD>Мы ушли не в ту степь. Мы начали дискутировать о принципах управления памятью и о системах типов.
VD>Данная тема вообще посвящена конкретным языкам. В них эти вопросы определены.
VD>Если ты хочешь создать другой язык, то Нитра позволяет это сделать относительно быстро, просто и получить автоматом поддержку IDE.

Не только IDE, но и как я понял можно автоматом получить лёгкую расширяемость и макросы.

VD>Если хочешь обсудить этот другой язык, то лучше создай отдельную тему. Можно даже не тут, а в Философии программирования. Там к нему присоединиться много народа. Мне есть что высказать по этому вопросу, но эта тема немного о другом.

Я же не просто про какой-то левый язык на базе Nitra спросил, а конкретно про возможность разделения части кодовой базы этого языка с Nemerle 2.0. Думаю возможность такого разделения-переиспользования должна быть как-то заранее учтена при разработке Nemerle 2.0 — и этот момент полностью относится к этой данной теме, IMO.

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

STD>Поучаствовать хочется, но есть сомнения реально ли это потянуть, так как нет знаний
STD>1. предметной области (компиляторостроение)

На то мы и делали Нитру, чтобы компиляторы могли делать люди не имеющие огромного опыта в компиляторостроении.

STD>2. самой nitra

Вот ее придется освоить. Но это не так сложно как кажется.

STD>Кроме того, C# — это очень сложный комплексный язык, где одна только спецификация пятой версии занимает более 500 страниц.
STD>Я сомневаюсь, что сейчас можно зайти со стороны, то есть не будучи автором nitra, и начать приносить реальную пользу.

Собственно именно потому что работа объемная и нужна помощь.

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

STD>Может, стоит перед тем, как звать людей делать C# и тем более Nemerle 2, нарисовать что-то попроще, чтобы было ясно, по пунктам, как делаются языки с применением nitra?

Ну, для тренировки — можно. Но я тебя уверяю, что работать над шарпом будет не сильно труднее. Даже может и проще, так как нужно реализовывать отдельные мелкие части языка, а не язык с нуля.

STD>Может, потенциальным участникам стоит сделать с вашей помощью что-то подобное? Это не должно занять много времени, но перспективы участия в разработке C# должны сильно проясниться, я полагаю.

Я не против. Лучше делать хоть, что-то. Если потом участники этого проекта смогут сделать статейку с описанием процесса, будет вообще замечательно.

Единственное что мне хотелось бы — это чтобы этот проект делал не я. Я могу консультировать, править баги (если они вылезут) и помогать решать проблемы.

STD>Потом хочется какого-то понимания, как будет устроен процесс работы.

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

Далее все очень просто. Шаги банальны и стандартны:
1. Пишется и тестируется в Visualizer-е грамматика в формате .nitra.
2. Описывается AST и mapping правил на него.
3. Пишется и тестируется (там же) типизация.

STD>Как будут ставится задачи, кто все это запроектирует, как будет тестироваться, когда и в каком формате будет проходить общение.

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

STD>Опыт этого раздела, например, показывает, что общение выходит достаточно рваным, так как какие-то вполне конкретные предментные вопросы могут оставаться без внимания долгое время.

Про рваный опыт не понял.

VD>>Со своей стороны мы будем помогать и обучать.

STD>Этого явно недостаточно, я считаю. Если говорить за себя, то не знаю досконально спецификацию C#, читаю IL-код не без проблем и ориентируюсь там в основном по комментариям из-чего он был сгенерирован. То есть даже часть генерации IL, которая не является чем-то nitra-специфичным, выглядит для меня сложно.

ОК, я буду участвовать в разработке нитра-шарпа и ставить задачи для других.

STD>Я могу представить сценарий, когда некто, разбирающийся в данной области сделает каркас, а потом нарежет большой объем сравнительно простой механической работы на маленькие куски и пояснит, как их реализовывать.

Ну, вот каркас для шарпа уже готов. Можно брать и развивать его.

Что касается этого микро-языка, то делать каракас для него мне категорически не хочется. Если уж браться за такой проект, то нужно чтобы он на 100% был создан людьми не имеющими отношения к разработке Найтры. Я буду курировать проект, объяснять что нужно делать и решать возникающие проблемы. Но делать все должны вы. Иначе это будет еще один проект в котором целиком разбираюсь только я.

STD>Тогда можно вложить в это свое время и понемногу раскурить предметку. Вариант, что все соберутся и начнут что-то осмысленное делать, периодически обращаясь к вам за вопросами, я как утопичный даже не рассматриваю.

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

STD>И, наконец, в gitter-конференции (где по какой-то причине нет никого из ведущих разработчиков языка) обсуждался вопрос целесообразности воспроизведения Nemerle на nitra в его текущем виде.

Сори. Я уже даже забыл (или не знал) что такое gitter-конференция. Почему бы было не обсуждать это здесь?

STD>Вот только несколько тем:
STD>- option как значимый тип и его поддержка в компиляторе
STD>- non-nullable types
STD>- методы расширения в стиле F# (обсуждалась поддержка свойств и расширения для статических классов)
STD>- захардкоженные конвенции (невозможно называть типы с маленькой буквы, например)
STD>И далее в таком духе. Это как дискуссия про nemerle base-level, только вместо фатального неприятия C#-программистами when вместо if, обсуждались чуть другие вещи.

Это все какие-то мелкие технические детали. Для начала нужно организовать совместную работу над проектом. Для начала надо воспроизвести C#. А далее каждый сможет эксперементировать с ним. Ну, а на следующем этапе забацаем немерл и решим все поднятые вопросы.

STD>Я понимаю, что перспективы Nemerle 2 еще более туманны, чем воспроизведенного на nitra C#, но есть ощущение, что именно это и привлекает внимание людей. У C# сейчас всё хорошо — есть кроссплатформенный roslyn, core clr, ahead of time компиляция в нативный код и тд. И лично меня не сильно интересует воспроизведение C# со всеми его недостатками, которые тянуться со времен первой версии. Полагаю, что я не один такой.

Воспроизведение C# нужно для того чтобы его можно было начать изменять и расширять. Это как с конструктором. Имея гору блоков Лего не так то просто создать модель красной площади. А вот имея модель красной площади уже не так трудно подправить отдельные ее недостатки.

STD>Это вопрос мотивации, потому как люди понимают, что сейчас какие-то вещи сделаны в C# или F# более оптимально чем в Nemerle. А есть еще и опыт других языков. И нужно, во-первых, понимание, какие задачи стоят в разработке Nemerle 2 (nitra в качестве подсистемы макросов здорово, но либо хочется еще профитов, либо нет понимания, к чему это ведет), во-вторых, открытая дискуссия по этим задачам. Было предложение создавать issue с proposal'ами в репозитории текущего Nemerle, но, имхо, это писать в никуда.

Дискуссия по шкуре не убитого медведя всегда будет крайне не продуктивной. Говорить сейчас о мелких деталях бессмысленно.

Мы имеем шанс показать индустрии как нужно создавать и развивать языки программирования.

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

Немерл нас научил главному. Язык может расширяться библиотеками. Натйра позволяет расширять библиотеками любые языки. Можно взять Шарп и переделать его в другой язык. А можно сделать свой удобный ДСЛ для своих нужд.

Но чтобы все это можно был делать надо реализовать каркас языка (языков). C# — отличный кондидат для тренировки. Работа уже начата и сделано довольно много.

STD>Резюмирую:
STD>- надо потренироваться на кошках, перед тем как браться за C#

ОК. Если есть такое желание, то можно реализовать этот мини язык. Давайте соберем команду и наладим общение.

STD>- надо определить архитектор(а/ов) / ведущещ(его/их) разработчик(а/ов)

Я могу быть координатором и консультантом. Ведущим разработчиком я не хочу быть по описанным выше причинам.

Мне кажется, что ведущий разработчик может определиться и сам в процессе работы. Возможно он и не особо буде нужен. Проект очень простенький. Мы на налаживание сборки больше времени убьем.

STD>- надо напилить маленьких понятных задач

Да как бы все задачи шаблонны. Выше я описал процесс. Этот миркро-язык нужен только чтобы изучить концепции Нитры. Затачи в нем настолько примитивны, что их проще определять по ходу действий.

STD>- надо обсуждать перспективы языка, которому посвящен раздел

Перспективы чего? Микро-языка? Это язык-игрушка. Единственная его перспектива попасть в качестве примера в обучающую статью по Нитре.

Или речь о расширяемом C# и Nemerle 2?

С ними даже не надо загадывать что в них будет в дальнейшем. Время самое покажет что в них надо добавить. Для начала нужно просто воспроизвести Шарпа, а далее начинать параллельно его расширять. Это будет точно так же как написание макросов Немрла. Каждый сможет сделать расширение и предложить его на суд зрителей. Только теперь расширения смогут быть куда серьезнее и качественнее.

STD>Это не требования, но без этого что-то поднять будет сложно, на мой взгляд. Потому как я, использующий в Nemerle в продакшене разработчик, на текущий момент более заинтересован в улучшении качества инфраструктуры и компилятора текущего Nemerle, чем в трате времени создание кальки на C# или тот же самый текущий Nemerle. Никто ведь не объяснил внятно, зачем и кому нужен расширяемый C# на nitra и переписанный Nemerle.

Nemerle реализован так, что его улучшение мало чем отличается от переписывания его заново. При этом разработка Nemerle вручную — это много человеколет и много багов, которые потом придется править.

Нитра задумывалась и разрабатывалась для того, чтобы можно было написать Nemerle правильно и без компромисов. Для того чтобы развивать его было не так тяжело и болезненно как сейчас. Мы учли в Нитре все проблемы имевшиеся в Nemerle.

Создать Nemerle на Нитре во много раз проще.

Я ответил на вопрос по Nemerle?

Теперь по C#. Нитра-C# нужен из следующих соображений:
1. C# имеет довольно внятную и полную спецификацию и огромную кодовую базу. Это позволит качественно верефицировать результат.
2. C# очень близок к Nemerle и 90% работы по нему можно будет (с небольшими изменениями) перенести на Nemerle 2.0.
3. Многие не приняли Nemerle из-за того, что он слишком далеко отошел от C#. Сделав Нитра-C# мы сможем предложить плюшки Nemerle (да еще и реализованные на новом уровне) огромному числу C#-программистов. Тем самым есть надежда создать достаточное комьюнити для развития Нитра-C#-а. А уже далее оно может повлиять и на развитие Нитры, и на развитие Nemerle-а.

VD>Теперь по C#. Нитра-C# нужен из следующих соображений:
VD>1. C# имеет довольно внятную и полную спецификацию и огромную кодовую базу. Это позволит качественно верефицировать результат.
VD>2. C# очень близок к Nemerle и 90% работы по нему можно будет (с небольшими изменениями) перенести на Nemerle 2.0.
VD>3. Многие не приняли Nemerle из-за того, что он слишком далеко отошел от C#. Сделав Нитра-C# мы сможем предложить плюшки Nemerle (да еще и реализованные на новом уровне) огромному числу C#-программистов. Тем самым есть надежда создать достаточное комьюнити для развития Нитра-C#-а. А уже далее оно может повлиять и на развитие Нитры, и на развитие Nemerle-а.

Лично мне C# совсем неинтересен, даже с макросами, даже в качестве песочницы. Я на нем не пишу и опробовать его мне просто негде. В отличии от F#.

Какие я вижу проблемы в реализации расширяемого F#:

• Significant whitespace синтаксис (хотя Nemerle тоже его поддерживает и, возможно, здесь проблем не будет).
  
• Глобальный вывод типов.
  
• Однопроходный компилятор, поэтому последовательность объявлений типов/функций и порядок файлов важен.
  
• Type Providers — генерят типы лениво и поддерживают так называемые erased types, которые стираются при компиляции.

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

V>Какие я вижу проблемы в реализации расширяемого F#:

V>* Significant whitespace синтаксис (хотя Nemerle тоже его поддерживает и, возможно, здесь проблем не будет).
V>* Глобальный вывод типов.
V>* Однопроходный компилятор, поэтому последовательность объявлений типов/функций и порядок файлов важен.
V>* Type Providers — генерят типы лениво и поддерживают так называемые erased types, которые стираются при компиляции.

F#, по описанным тобой причинам, плохо IDE-зируемый язык. Тайп провайдеры не проблема, а вот однопроходная схема и глобальный вывод типов — это приговор. При этом по возможностям от от Немерла мало чем отличается.

Что касается отступного парсер, то ясно как это дело реализовать, но это надо делать, а приоритет у этого дела не высокий.

C# же можно использовать как базу для Nemerle 2.0.

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

VD>Уверен, что в Nitra придется многое усовершенствовать, так что мы (разработчики ядра Nitra) видимо будем вынуждены уделять много времени именно Nitra. По сему нужны добровольцы которые будут писать код для Nemerle 2.0 и расширяемого C#.

У Jetbrains закончились деньги на разработчиков?

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

W>У Jetbrains закончились деньги на разработчиков?

Не, но на нас они их тратить нетхотят. Они их на Котлин, например, тратят.

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

VD>По Nemerle 2.0 задача по сложнее, так как нужно еще написать парсер Nemerle на Nitra

Влад, я не совсем понял принципиальный момент: раз мы пишем Немерле-2, используя Нитру, в конечном итоге мы должны получить некий "лаконичный язык" в виде экзешника. Но ведь Немерле-2 будет таким же расширяемым "сам собой", как и Немерле-1! Получается, расширения к Н-2 будут писаться на самом же Н-2! Но ведь "расширяемые правила" у нас существуют только в Нитре! Какбыть?

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

K>Влад, я не совсем понял принципиальный момент: раз мы пишем Немерле-2, используя Нитру, в конечном итоге мы должны получить некий "лаконичный язык" в виде экзешника. Но ведь Немерле-2 будет таким же расширяемым "сам собой", как и Немерле-1! Получается, расширения к Н-2 будут писаться на самом же Н-2! Но ведь "расширяемые правила" у нас существуют только в Нитре! Какбыть?

Тут противоречий нет. Nitra написана на Nitra и одновременно на Nemerle. Nemerle может быть написан на Nemerle и одновременно на Nitra. Просто какая-то часть Nitra станет составной частью Немерла.

В Nemerle 1 ест подсистема парсинга, АСТ, типизированный АСТ, подсистема макросов и т.п. В Nemerle 1 их место займет Nitra. Естественно Нитру придется интегрировать в Nemerle 2, чтобы швов не было видно. Но это не сложно.

В итоге Nemerle и Nitra должны переплестись и стать одним целым. Код в Nitra пишется на Nemerle, сам Nemerle будет реализован на Nitra.

Разница только в том, что Nitra можно будет использовать не только для создания Nemerle, но и для любых других языков.

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


VD>Не, но на нас они их тратить нетхотят. Они их на Котлин, например, тратят.

Получается что проект мертворожденный и не нужный.
Зачем тогда кому-то тратить время бесплатно пилить ваше поделие? Какая-то мотивация кроме саморазвития присутствует?
Для саморазвития разрабу можно найти проекты с куда большим visibility для своего резюме.