Re[6]: Nitra-C# и Nitra-Nemerle
От: -n1l-  
Дата: 15.01.16 15:12
Оценка:
Так вам еще помощники нужны?
Re[6]: Nitra-C# и Nitra-Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.01.16 18:53
Оценка:
Здравствуйте, 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.

Если хочешь обсудить этот другой язык, то лучше создай отдельную тему. Можно даже не тут, а в Философии программирования. Там к нему присоединиться много народа. Мне есть что высказать по этому вопросу, но эта тема немного о другом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Nitra-C# и Nitra-Nemerle
От: Evgeny.Panasyuk Россия  
Дата: 15.01.16 19:06
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>ЗЫ

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

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

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


Я же не просто про какой-то левый язык на базе Nitra спросил, а конкретно про возможность разделения части кодовой базы этого языка с Nemerle 2.0. Думаю возможность такого разделения-переиспользования должна быть как-то заранее учтена при разработке Nemerle 2.0 — и этот момент полностью относится к этой данной теме, IMO.
Re[8]: Nitra-C# и Nitra-Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.01.16 21:09
Оценка: 10 (1)
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


Само собой.

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


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

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

В любом случае тут есть что обсудить с народом. Например, что брать из С++? Очевидно, что С-шный препроцессор — это зло и его брать не следует. А вот нужно ли брать из С++ шаблоны со всеми сложностями и проблемами — это большой вопрос. Мне кажется, что полные по тюрингу шаблоны в языке с макросами не нужны.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Nitra-C# и Nitra-Nemerle
От: STDray http://stdray.livejournal.com
Дата: 28.01.16 22:51
Оценка: 9 (3)
Здравствуйте, 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.
Re[2]: Nitra-C# и Nitra-Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.01.16 08:33
Оценка:
Здравствуйте, 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-а.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Nitra-C# и Nitra-Nemerle
От: vaskir Россия vaskir.blogspot.com
Дата: 30.01.16 09:43
Оценка:
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#:

Re[4]: Nitra-C# и Nitra-Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.01.16 11:36
Оценка:
Здравствуйте, vaskir, Вы писали:

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


V>* Significant whitespace синтаксис (хотя Nemerle тоже его поддерживает и, возможно, здесь проблем не будет).

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

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

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

C# же можно использовать как базу для Nemerle 2.0.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Отредактировано 30.01.2016 12:27 VladD2 . Предыдущая версия .
Re: Nitra-C# и Nitra-Nemerle
От: woah  
Дата: 01.02.16 22:31
Оценка:
Здравствуйте, VladD2, Вы писали:

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


У Jetbrains закончились деньги на разработчиков?
Re[2]: Nitra-C# и Nitra-Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.02.16 07:38
Оценка:
Здравствуйте, woah, Вы писали:

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


Не, но на нас они их тратить нетхотят. Они их на Котлин, например, тратят.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Nitra-C# и Nitra-Nemerle
От: Kolesiki  
Дата: 13.02.16 19:52
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Влад, я не совсем понял принципиальный момент: раз мы пишем Немерле-2, используя Нитру, в конечном итоге мы должны получить некий "лаконичный язык" в виде экзешника. Но ведь Немерле-2 будет таким же расширяемым "сам собой", как и Немерле-1! Получается, расширения к Н-2 будут писаться на самом же Н-2! Но ведь "расширяемые правила" у нас существуют только в Нитре! Какбыть?
Re[2]: Nitra-C# и Nitra-Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.02.16 13:59
Оценка:
Здравствуйте, 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, но и для любых других языков.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Nitra-C# и Nitra-Nemerle
От: woah  
Дата: 14.02.16 14:29
Оценка:
Здравствуйте, VladD2, Вы писали:


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


Получается что проект мертворожденный и не нужный.
Зачем тогда кому-то тратить время бесплатно пилить ваше поделие? Какая-то мотивация кроме саморазвития присутствует?
Для саморазвития разрабу можно найти проекты с куда большим visibility для своего резюме.
Re[4]: Nitra-C# и Nitra-Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.02.16 10:49
Оценка: +1
Здравствуйте, woah, Вы писали:

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


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


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

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

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

Да хоть в крестики нолики играй для саморазвития и резюме. Нам резюмисты/карьеристы не нужны. Нам нужны люди способные делать сложные вещи и способные самостоятельно оценивать перспективность.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Отредактировано 15.02.2016 16:08 VladD2 . Предыдущая версия .
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.