Мы подошли к моменту когда на 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>По 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>По сему нужны добровольцы которые будут писать код для 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>В идеале конечно хотелось бы иметь какую-нибудь совместимость между макро библиотеками (то есть из макро-ядра вырастить разные языки, но чтобы была возможность переиспользовать схожие макросы между языками).
Для высокоуровневых ДСЛ такое вполне возможно.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>В дальнейшем, если кому интересно, можно занятием создания бэкэнов позволяющих компилировать код под другие платформы (Java, LLVM). Реализовав бэкнды под эти платформы мы сможем автоматически портировать на них Nitra, C#, Nemerle и другие языки использующие символы дотнета.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Насколько реально сделать макро-ядро Nemerle 2.0 независимым от системы типов .NET?
Независимое от системы типов почти не реально, так как от какой-то системы типов язык должен зависеть. И если он зависит от другой системы типов, то он становится другим языком. Система типов она ведь задает основные возможности языка.
Но важно понимать, что рантайм дотнета и система типов дотнета — это соврешенно разные вещи. Систему типов дотнета можно воспроизвести и на базе Ява-машины (хотя там будут трудности с вэйлью-типами), и даже на базе нэйтива/LLVM. Можно даже сделать вариант Немерла без ЖЦ, но при этом нужно подумать о том как в таком языке управлять памятью. Например, можно создать вариант с подсчетом ссылок. Но, при этом, нужно понимать, что написание кода на таком языке будет несколько отличаться. И программы не будет полностью совместимы с немерлом для управляемых сред.
EP>Например чтобы на той же базе можно было сделать язык с более продвинутой системой типов, изначально нацеленный на native/LLVM?
А что ты понимаешь под "более продвинутой системой типов"? Если под этим понимается поддержка шаблонов аля С++-шаблоны, то это сделать можно. Но система типов Дотнета очень даже продвинутая. Гибкость системы типов дотнета во многом завязана на использование ЖЦ. Для меня язык с ручным управлением памятью имеет менее продвинутую систему типов, например.
EP>В идеале конечно хотелось бы иметь какую-нибудь совместимость между макро библиотеками (то есть из макро-ядра вырастить разные языки, но чтобы была возможность переиспользовать схожие макросы между языками).
Для начала хочется услышать четкую постановку задачи. Что мы хотим сделать? Попробую простить задачу приведя возможные варианты. И так мы можем хотеть получить:
1. Язык похожий на Немерл, но исполняемые модули которого будут нативными или LLVM-ыми. Тут основная проблема — это поддержка ЖЦ. Если ее реализовать, или ограничиться, например, подсчетом ссылок (ЖЦ для бедных), то создать такой язык можно и это относительно не сложно. Создание же и поддержка в языке ЖЦ для нэтива — это довольно сложная задача. Плюс ко всему в этом не так много смысла, так как уже есть компиляторы с дотнет-сборок в нэйтив код.
2. Мы хотим расширить систему типов Немерла теми или иными фичами, например, шаблонами похожими на С++-ные. Это сделать довольно просто.
3. Нечто среднее между пунктами 1 и 2 — язык компилируемый в нэйтив и имеющий расширенную систему типов.
Макросы — это не более чем плагины к компилятору которые реинтерптируют некоторый синтаксис языка (меняют семантику) или вводят новый. В итоге макрос должен порождать какой-то код. Но если даже у языка, реализованного под разные платформы, идентичный синтаксис — это еще не значит, что одинаковый код будет работать для обоих платформ. Макрос рассчитанный на нйэтив без поддержки ЖЦ не сможет использовать некоторые фичи доступные для управляемого варианта языка. В обратную сторону поддержать совместимость проще, но тоже можно нарваться на грабли.
Короче, можно все. Вопрос в стоимости решения и в геморрое который будет возникать при использовании кода под разные платформы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, VladD2, Вы писали:
VD>>По сему нужны добровольцы которые будут писать код для Nemerle 2.0
EP>Насколько реально сделать макро-ядро Nemerle 2.0 независимым от системы типов .NET? EP>Например чтобы на той же базе можно было сделать язык с более продвинутой системой типов, изначально нацеленный на native/LLVM? EP>В идеале конечно хотелось бы иметь какую-нибудь совместимость между макро библиотеками (то есть из макро-ядра вырастить разные языки, но чтобы была возможность переиспользовать схожие макросы между языками).
Как ты себе это представляешь?
Вот, допустим, есть макрос, реализующий SQL. Написанный для Nemerle. Как ты его заюзаешь в С++, ведь у макроса внутри немерлевые потроха?
Это разве что макросы высшего порядка (т.е. зовущие другие макросы) можно сделать кросс-языковыми, а первичные макросы — имхо, никак.
Здравствуйте, jazzer, Вы писали:
EP>>В идеале конечно хотелось бы иметь какую-нибудь совместимость между макро библиотеками (то есть из макро-ядра вырастить разные языки, но чтобы была возможность переиспользовать схожие макросы между языками). J>Как ты себе это представляешь? J>Вот, допустим, есть макрос, реализующий SQL. Написанный для Nemerle. Как ты его заюзаешь в С++, ведь у макроса внутри немерлевые потроха? J>Это разве что макросы высшего порядка (т.е. зовущие другие макросы) можно сделать кросс-языковыми, а первичные макросы — имхо, никак.
Да, естественно только часть обобщённых макросов, не завязанных на различия в типах целевых языков (либо специально отвязанных абстракциями от этих различий).
Я хочу помочь в разработке nemerle и/или nitra.
Берите меня. Мне нравится nemerle, только я его не знаю, но готов изучать, пламенный мотор вместо сердца присутствует, можете не сомневаться.
Здравствуйте, 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>Макросы — это не более чем плагины к компилятору которые реинтерптируют некоторый синтаксис языка (меняют семантику) или вводят новый. В итоге макрос должен порождать какой-то код. Но если даже у языка, реализованного под разные платформы, идентичный синтаксис — это еще не значит, что одинаковый код будет работать для обоих платформ. Макрос рассчитанный на нйэтив без поддержки ЖЦ не сможет использовать некоторые фичи доступные для управляемого варианта языка. В обратную сторону поддержать совместимость проще, но тоже можно нарваться на грабли.
Да, это понятно. Выше уже подсказали пример где макросы легко переиспользовать в разных языках — макросы высшего порядка.
Здравствуйте, WolfHound, Вы писали:
WH>Nemerle 2.0 это язык под .НЕТ.
Уточню. Nemerle — это язык проектировавшийся под .Net. Но в принципе его (как и любой другой язык дотнета) можно портировать на другие платформы, если написать для них бэкэнд поддерживающий сериализацию и десериализацию метаданных и кода, а так же реализовать рантайм необходимый для работы языка (о библиотеках скромно умолчим).
Так что в принципе, Nemerle 2.0 можно портировать и под другие платформы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, s22, Вы писали:
s22>Лучше бак энд для джаваскрипт....
Такое есть и для Nemerle 1.0. Он находится в составе проекта NemerleWeb. Естественно, что сделать аналог для Nemerle 2.0 будет так же можно. Скажу больше бэкэнд делается для АСТ в который может преобразовываться не только Nemerle 2.0, но и любой другой язык для дотнета сделанный на Nitra. Так что, например, C# тоже можно будет преобразовывать в JavaScript, если такой бэкэнд сделать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, jazzer, Вы писали:
J>Это разве что макросы высшего порядка (т.е. зовущие другие макросы) можно сделать кросс-языковыми, а первичные макросы — имхо, никак.
Если макросы (или нечто их заменяющее) будут работать на уровне АСТ-а дотнета, то их можно будет применять для любого языка основанного на этом АСТ-е.
Синтакси, естественно, придется написать свой для каждого языка. А вот реализацию можно будет иметь общую для группы языков. Так что Nemerle 2.0 и C# могут иметь общие макросы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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.
Если нам не помогут, то мы тоже никого не пощадим.
