_>Это решение снизит количество желающих попробовать немерле. Ставить 15 студию, специально вряд ли кто будет. У меня знакомый до сих пор в 2005 работает. Для привлечения народа, нужно снизить сложность вхождения. Что бы немерл в 3 щелчка подключался к текущим проектам. С этой точки зрения, желательно поддерживать все версии начиная с 2008. Хотя я сам за 15. Как я понял, это понизит сложность и немерл в релиз быстрее выйдет

Человек который работает в 2005-й студии и не имеет, ни дома ни на офисе 2015-й, хотя бы для личного развития, — не перейдёт на другой язык ни при каких обстоятельствах. Будут любые отмазы чтобы остаться "в зоне комфорта". Предыдущее поколение таких людей пилит вечность на Delphi 7.

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

VD>Насколько нужно соблюдать уникальные особенности Nemerle 1?

Не нужно.

VD>Может быть лучше максимально привести Nemerle 2 к спецификации C#, реализовав только действительно удобные и часто используемые отличия?

Лучше.

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

>Пока что мы планируем для этого использовать CCI Metedata. Если будут проблемы, будем ковырять Розлин (он на отпочковался от CCI Metedata).

Посмотрите в сторону dnlib. Это такой Cecil на стероидах, на его основе сейчас работают de4dot, ConfuserEx и ILRepack.

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

VD>Речь идет о фреймворке на котором работает сама Найтра и компиляторы созданные на ней.

Тогда я бы не парился. 4.5 это вроде как VS 2012, т.е. уже три года. Кто не спрятался, тот не виноват.

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

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

IT>>Лучше.

VD>OK

VD>Стоит ли поддерживать фреймворки до 4.5? В 4.5 есть разные полезные вещи вроде ImmutableArray. Интеграцию мы уже перевели на 4.5+, т.е. в расчете на VS 2013 и старше. А в релизе, скорее всего, будем рассчитать уже на 2015 студию.

Лучше начать с 2015 и .NET 4.6, а там уже смотреть нужно ли прикладывать усилия на более раннюю версию.
Студии 2012, 2013 и 2015 совместимы между собой по проектам и обновление практически не вызывает никаких проблем.

Кстати а с .NET Core будет работать ?

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

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

_NN>>Лучше начать с 2015 и .NET 4.6, а там уже смотреть нужно ли прикладывать усилия на более раннюю версию.

VD>Фарш невозможно провернуть назад. Если начать с VS 2015, то предыдущих версий уже не будет поддерживаться. Сейчас поддерживается 2013-я.
Ну тогда только 2015 и поддерживать.
Не забыть проверить совместимость с 2015 Community Edition.

Фичи C# 6 только там можно использовать и никто не переживает.

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

_>Что бы немерл в 3 щелчка подключался к текущим проектам. С этой точки зрения, желательно поддерживать все версии начиная с 2008. Хотя я сам за 15. Как я понял, это понизит сложность и немерл в релиз быстрее выйдет

Думаю, что это уравнение с несколькими параметрами. Учитывая, что силы у нас ограниченные мы можем или потратить больше сил на совместимость с VS 200x, или потратить эти силы на создание более качественной поддержки VS 2013+.

Учитывая, что я скорее согласен с hi_octane

Автор: hi_octane
Дата: 12.08.15

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

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

Я вот рассуждаю стоит ли тратить время на повторение всех отличий Немерла от Шарпа, или можно просто взять за основу спецификацию шарпа.

Например, Nemerle имеет отличающиеся от Шарпа правила обработки директив using. Причем речь идет не о возможности "открытия" классов, а именно об уникальном алгоритме при обработке using-ов. Думаю, что он получился таким просто потому что авторы Немерла не разобрались в алгоритмах Шарпа или накосявили. Возможно, конечно, что они пытались его улучшить, но по факту он получился запутанным и имел много багов, которые "замазывались" потом нами.

Собственно вопрос к комьюнити: Насколько нужно соблюдать уникальные особенности Nemerle 1? Может быть лучше максимально привести Nemerle 2 к спецификации C#, реализовав только действительно удобные и часто используемые отличия?

При это речь не идет об синтаксических особенностях или особенностях типизации. Речь идет об отличиях от стандарта Шарпа на уровне пространств имен и типов.

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

IT>Лучше.

OK

Стоит ли поддерживать фреймворки до 4.5? В 4.5 есть разные полезные вещи вроде ImmutableArray. Интеграцию мы уже перевели на 4.5+, т.е. в расчете на VS 2013 и старше. А в релизе, скорее всего, будем рассчитать уже на 2015 студию.

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

VD>Стоит ли поддерживать фреймворки до 4.5?

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

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

IT>Чем больше фреймворков будет поддерживаться, тем лучше. Но, конечно, без фанатизма. Если ImmutableArray очень очень нужен и в ранних версиях его никак нельзя сэмулировать или подменить, то пусть будет 4.5.

Речь идет о фреймворке на котором работает сама Найтра и компиляторы созданные на ней. Целевой (target) фреймворк может быть любой. Пока что мы планируем для этого использовать CCI Metedata. Если будут проблемы, будем ковырять Розлин (он на отпочковался от CCI Metedata).

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

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

Просьба цитировать вопросы на которые дается ответ. Не все читают форум в древесном режиме.

DR>В идеале, общая с C# функциональность должна работать по спецификации C#.

У Немерла есть несколько решений которые мощнее чем в Шарпе. Например, в Шарпе имя A.B будет считаться неоднозначным если есть более одного A в области видимости. Немерл, же делает спекулятивный поиск и выберет то A у которого есть B. Это сложнее в реализации и медленнее, но иногда полезно.

Если забить и на такие фичи, то можно упростить (а, значит и ускорить) разработку Nemerle 2, но при этом будет чуть меньше гибкости. В прочем, те кто пишет на Шарпе от этой не гибкости не сильно страдают. Так что можно забить и на эти особенности.

DR>Поддерживать старые фреймворки для самой Нитры ни к чему.

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

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

IT>Тогда я бы не парился. 4.5 это вроде как VS 2012, т.е. уже три года. Кто не спрятался, тот не виноват.

А, если минимальной будет 2015-я и, соответственно, 4.6-й фреймворк? (учитывая, что релиз не завтра будет)

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

VD>А, если минимальной будет 2015-я и, соответственно, 4.6-й фреймворк? (учитывая, что релиз не завтра будет)

Если делать только поддержку VS2015+, то 4.5 не нужен.

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

_NN>Лучше начать с 2015 и .NET 4.6, а там уже смотреть нужно ли прикладывать усилия на более раннюю версию.

Фарш невозможно провернуть назад. Если начать с VS 2015, то предыдущих версий уже не будет поддерживаться. Сейчас поддерживается 2013-я.

_NN>Студии 2012, 2013 и 2015 совместимы между собой по проектам и обновление практически не вызывает никаких проблем.

Зато по API они совместимы только сверху вниз. Обратной совместимости нет. А, 2015-я студия на Розлине и имеет свою проектную систему.

_NN>Кстати а с .NET Core будет работать ?

Интеграция, естественно — нет. Остальное — должно. Привязка к платформе из-за использования SRE. От этого мы уйдем.

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

VD>Nemerle довольно близкий к C# язык на уровне системы типов. Но все же у него есть ряд отличий. Большинство из этих отличий не принципиальные, а произошли потому как так получилось при реализации.

VD>Я вот рассуждаю стоит ли тратить время на повторение всех отличий Немерла от Шарпа, или можно просто взять за основу спецификацию шарпа.

VD>Например, Nemerle имеет отличающиеся от Шарпа правила обработки директив using. Причем речь идет не о возможности "открытия" классов, а именно об уникальном алгоритме при обработке using-ов. Думаю, что он получился таким просто потому что авторы Немерла не разобрались в алгоритмах Шарпа или накосявили. Возможно, конечно, что они пытались его улучшить, но по факту он получился запутанным и имел много багов, которые "замазывались" потом нами.

VD>Собственно вопрос к комьюнити: Насколько нужно соблюдать уникальные особенности Nemerle 1? Может быть лучше максимально привести Nemerle 2 к спецификации C#, реализовав только действительно удобные и часто используемые отличия?

VD>При это речь не идет об синтаксических особенностях или особенностях типизации. Речь идет об отличиях от стандарта Шарпа на уровне пространств имен и типов.



Предложение, для чего он нужен и что я ожидаю от Nemerle 2 — http://maiss.us/nemerle.2.html.
Это только информация. Возможно, она Вам пригодится.

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

E>Предложение, для чего он нужен и что я ожидаю от Nemerle 2 — http://maiss.us/nemerle.2.html.
E>Это только информация. Возможно, она Вам пригодится.
Ты смерти моей хочешь?
Мой мозг расплавился и растёкся по полу.
Сижу ржу как идиот.

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

E>Предложение, для чего он нужен и что я ожидаю от Nemerle 2 — http://maiss.us/nemerle.2.html.
E>Это только информация. Возможно, она Вам пригодится.

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

Жаль, сайт не на русском. В английском ошибки через слово — больно читать.

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

VD>Nemerle довольно близкий к C# язык на уровне системы типов. Но все же у него есть ряд отличий. Большинство из этих отличий не принципиальные, а произошли потому как так получилось при реализации.

Енамы можно будет в генерик-типах заводить? Почему в генерике невозможно объявить влож. Enum и Variant? Ну и прочие не принципиальные отличия будут устраняться?

По теме соглашусь с коллегами — что-то ранее MSVS 2015 в поддержке не нуждается.

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

X>Енамы можно будет в генерик-типах заводить? Почему в генерике невозможно объявить влож. Enum и Variant? Ну и прочие не принципиальные отличия будут устраняться?

Можно. Сейчас это просто косяк реализации. Хотя, по моему мнению, лучше энумы в дженерик-типах не объявлять. Это плохая практика.

X>По теме соглашусь с коллегами — что-то ранее MSVS 2015 в поддержке не нуждается.

ОК, тогда как она выйдет перейдем на ее и будем ориентироваться на 2015+. Код, естественно, можно будет компилировать под любую платформу, а вот плагины только под 2015+.

>> В 4.5 есть разные полезные вещи вроде ImmutableArray. Интеграцию мы уже перевели на 4.5+, т.е. в расчете на VS 2013 и старше. А в релизе, скорее всего, будем рассчитать уже на 2015 студию.

https://www.nuget.org/packages/System.Collections.Immutable/1.1.37-beta-23019

И, пожалуйста, сразу всё с нормальной поддержкой NuGet. Оптимально чтобы через него подтягивался не только рантайм, но и сам компилятор.

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

IT>Кто не спрятался, тот не виноват.

4.5 не ставится под WinXP ни под каким соусом, а заказчики совместимость всё ещё повсеместно требуют.

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

K>Посмотрите в сторону dnlib. Это такой Cecil на стероидах, на его основе сейчас работают de4dot, ConfuserEx и ILRepack.

А, какие у него преимущества есть?

Я на CCI Metedata выбор остановил потому что он использован в Розлине и это реализация от Майкрософт. Есть вероятность, что его будут и дальше поддерживать и развивать. А, не будут, так хотя бы есть шанс выкорчевать его клон из Розлина и свалить на него.

Моно у меня доверия не вызывает. Была еще интересная реализация из IKVM, но боюсь, что его самостоятельно поддерживать придется.

В принципе, мы будем стараться все абстрагировать от конкретных сторонних библиотек. Можно будет сделать сколько угодно внешних бэкэндов на базе любых библиотек. В том числе даже можно сделать бэкнды для Явы и LLVM. Вот только наших рук на это все не хватит. По сему мы сделаем референсную реализацию (скорее всего на CCI Metedata), а уж кто хочет, пусть делают свои на чем угодно.

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

K>И, пожалуйста, сразу всё с нормальной поддержкой NuGet. Оптимально чтобы через него подтягивался не только рантайм, но и сам компилятор.

NuGet мы уже используем в Нитре для плагинов к IDE. Учитывая, что проблем с SRE не будет, сделать NuGet-распространение для второго Немерла будет по проще. Но есть проблема даймонд-наследования, которую не ясно как решать. Ведь если кто-то собрал компоненты с разными версиями рантйм-библиотек, то собрать их в одном модуле уже не выйдет.

Сейчас эта проблема решается за счет того, что немерловый инсталлятор ставт в GAC специальную прокси-сборку, которая заставляет подавить версионирование сборок дотнета и использовать всеми одной копии Nemerle.dll.

Вроде как в 4.5+ фреймворках стратегия версионирвоания изменилась. Так что, возможно, получится обойтись без этих приседаний. Тогда с NuGet-распространение проблем быть не должно. Но, надо пробовать.

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

VD>Но есть проблема даймонд-наследования, которую не ясно как решать. Ведь если кто-то собрал компоненты с разными версиями рантйм-библиотек, то собрать их в одном модуле уже не выйдет.

NuGet прописывает в таких случаях binding redirect в App.config, заставляя всех использовать ту самую последнюю версию.

Например, для JSON.NET очень часто появляется запись вида:

 <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-7.0.0.0" newVersion="7.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>

Насколько я знаю bindingRedirect поддерживается как минимум начиная с .NET 2.0.

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

K>NuGet прописывает в таких случаях binding redirect в App.config, заставляя всех использовать ту самую последнюю версию.

Это работает только для exe-шников. А, есть еще DLL-и и сама студия. У студии тоже можно прописать редиректы, но это в разы сложнее и NuGet-ом, наверняка, не делается.

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

VD>Это работает только для exe-шников.

Если dll-ка подключается через NuGet, то у неё в зависимостях прописан Nemerle конкретной версии. Что и является основанием для прописывания binding redirect. Для студии всё вроде как лечится посредством добавления обработчика AppDomain.AssemblyResolve. Опять же никто не мешает при сборке не указывать Specific Version.

Таки да

The event handler can return a different version of the assembly than the version that was requested.

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

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

IT>>Кто не спрятался, тот не виноват.

K>4.5 не ставится под WinXP ни под каким соусом, а заказчики совместимость всё ещё повсеместно требуют.

Софт под чугунные промышенные железки пишете?

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

С>Софт под чугунные промышенные железки пишете?

Да даже когда под обычные офисные. Оборудование устаревает, а менять его никто не торопится. 2007-ой Word с файрфоксом работают, всех всё устраивает.
Не говоря уже о случаях, когда к компьютеру подключена какая-нибудь стоящая пару десятков килобаксов древняя железяка, драйверов для которой на что-то кроме Win2K/XP нет и уже не предвидится.
Со вторым столкнулся когда начали делать софт для автосервисов, занимающихся в том числе прошивками мозгов автомобилей. Там не то что драйвера, там сами железки для старых моделей уже не выпускают, а народ на них до сих пор катается.

В итоге городятся костыли типа вот этого.

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

С>Софт под чугунные промышенные железки пишете?
У нас требуется поддержка XP, клиенты только вот на 7-ку переползают.
Могу сказать, что клиенты у нас довольно крупные и серьёзные компании, а посему всем там ясно, что просто так менять рабочую систему не имеет большого смысла.
Более того, у нас даже требование даже .NET 3.5 потому что он с 7-кой идет из коробки.

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

K>Таки да
K>

K>The event handler can return a different version of the assembly than the version that was requested.

Это очень ненадежный путь. Обработчик может быть перехвачен кем угодно.

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

K>4.5 не ставится под WinXP ни под каким соусом, а заказчики совместимость всё ещё повсеместно требуют.

Ограничений на целевую платформу (т.е. на то где может выполняться скомпилированная сборка) не будет. Речь только о рантайме на котором может работать сам Nemerle 2.

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

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

IT>>Тогда я бы не парился. 4.5 это вроде как VS 2012, т.е. уже три года. Кто не спрятался, тот не виноват.

VD>А, если минимальной будет 2015-я и, соответственно, 4.6-й фреймворк? (учитывая, что релиз не завтра будет)
Это решение снизит количество желающих попробовать немерле. Ставить 15 студию, специально вряд ли кто будет. У меня знакомый до сих пор в 2005 работает. Для привлечения народа, нужно снизить сложность вхождения. Что бы немерл в 3 щелчка подключался к текущим проектам. С этой точки зрения, желательно поддерживать все версии начиная с 2008. Хотя я сам за 15. Как я понял, это понизит сложность и немерл в релиз быстрее выйдет

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

VD>Ограничений на целевую платформу (т.е. на то где может выполняться скомпилированная сборка) не будет. Речь только о рантайме на котором может работать сам Nemerle 2.

Насколько я понимаю одно из применений Nemerle 2 это встраиваемые языки , а значит язык по месту использования, т.е. нужен сам рантайм то бишь Nemerle 2.
Такой сценарий очевидно не будет поддерживаться.

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

_NN>Насколько я понимаю одно из применений Nemerle 2 это встраиваемые языки , а значит язык по месту использования, т.е. нужен сам рантайм то бишь Nemerle 2.
_NN>Такой сценарий очевидно не будет поддерживаться.

Любой язык созданные на основе Nitra может быть встроен в другой Nitra-язык. Nemerle не исключение. Сама Nitra использует Nemerle как встроенный язык. Сейчас мы просто используем Nemerle как компонент. В будущем будем заменим его на собственную версию Nemerle 2.