Nemerle довольно близкий к C# язык на уровне системы типов. Но все же у него есть ряд отличий. Большинство из этих отличий не принципиальные, а произошли потому как так получилось при реализации.
Я вот рассуждаю стоит ли тратить время на повторение всех отличий Немерла от Шарпа, или можно просто взять за основу спецификацию шарпа.
Например, Nemerle имеет отличающиеся от Шарпа правила обработки директив using. Причем речь идет не о возможности "открытия" классов, а именно об уникальном алгоритме при обработке using-ов. Думаю, что он получился таким просто потому что авторы Немерла не разобрались в алгоритмах Шарпа или накосявили. Возможно, конечно, что они пытались его улучшить, но по факту он получился запутанным и имел много багов, которые "замазывались" потом нами.
Собственно вопрос к комьюнити: Насколько нужно соблюдать уникальные особенности Nemerle 1? Может быть лучше максимально привести Nemerle 2 к спецификации C#, реализовав только действительно удобные и часто используемые отличия?
При это речь не идет об синтаксических особенностях или особенностях типизации. Речь идет об отличиях от стандарта Шарпа на уровне пространств имен и типов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Стоит ли поддерживать фреймворки до 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).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Просьба цитировать вопросы на которые дается ответ. Не все читают форум в древесном режиме.
DR>В идеале, общая с C# функциональность должна работать по спецификации C#.
У Немерла есть несколько решений которые мощнее чем в Шарпе. Например, в Шарпе имя A.B будет считаться неоднозначным если есть более одного A в области видимости. Немерл, же делает спекулятивный поиск и выберет то A у которого есть B. Это сложнее в реализации и медленнее, но иногда полезно.
Если забить и на такие фичи, то можно упростить (а, значит и ускорить) разработку Nemerle 2, но при этом будет чуть меньше гибкости. В прочем, те кто пишет на Шарпе от этой не гибкости не сильно страдают. Так что можно забить и на эти особенности.
DR>Поддерживать старые фреймворки для самой Нитры ни к чему.
Тут вопрос в поддерживаемых студиях. Если мы выбираем 4.6, то студия будет поддерживаться только 2015 и старше. Но это несколько упрощает нам задачу. Учитывая, что до релиза еще долеко, я тоже склоняюсь к тому чтобы забить на поддержку старых версий фреймворка и студии.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, IT, Вы писали:
IT>>Лучше.
VD>OK
VD>Стоит ли поддерживать фреймворки до 4.5? В 4.5 есть разные полезные вещи вроде ImmutableArray. Интеграцию мы уже перевели на 4.5+, т.е. в расчете на VS 2013 и старше. А в релизе, скорее всего, будем рассчитать уже на 2015 студию.
Лучше начать с 2015 и .NET 4.6, а там уже смотреть нужно ли прикладывать усилия на более раннюю версию.
Студии 2012, 2013 и 2015 совместимы между собой по проектам и обновление практически не вызывает никаких проблем.
Здравствуйте, _NN_, Вы писали:
_NN>Лучше начать с 2015 и .NET 4.6, а там уже смотреть нужно ли прикладывать усилия на более раннюю версию.
Фарш невозможно провернуть назад. Если начать с VS 2015, то предыдущих версий уже не будет поддерживаться. Сейчас поддерживается 2013-я.
_NN>Студии 2012, 2013 и 2015 совместимы между собой по проектам и обновление практически не вызывает никаких проблем.
Зато по API они совместимы только сверху вниз. Обратной совместимости нет. А, 2015-я студия на Розлине и имеет свою проектную систему.
_NN>Кстати а с .NET Core будет работать ?
Интеграция, естественно — нет. Остальное — должно. Привязка к платформе из-за использования SRE. От этого мы уйдем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, _NN_, Вы писали:
_NN>>Лучше начать с 2015 и .NET 4.6, а там уже смотреть нужно ли прикладывать усилия на более раннюю версию.
VD>Фарш невозможно провернуть назад. Если начать с VS 2015, то предыдущих версий уже не будет поддерживаться. Сейчас поддерживается 2013-я.
Ну тогда только 2015 и поддерживать.
Не забыть проверить совместимость с 2015 Community Edition.
Фичи C# 6 только там можно использовать и никто не переживает.
Здравствуйте, 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>Это только информация. Возможно, она Вам пригодится.
Ты смерти моей хочешь?
Мой мозг расплавился и растёкся по полу.
Сижу ржу как идиот.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, enlightenihi, Вы писали:
E>Предложение, для чего он нужен и что я ожидаю от Nemerle 2 — http://maiss.us/nemerle.2.html. E>Это только информация. Возможно, она Вам пригодится.
Читал выборочно, но в конце говорится, что предшествующий текст доказывает необходимость наличия лексерных правил, но Нитра же генерирует безлексерные парсеры.
Жаль, сайт не на русском. В английском ошибки через слово — больно читать.
Здравствуйте, VladD2, Вы писали:
VD>Nemerle довольно близкий к C# язык на уровне системы типов. Но все же у него есть ряд отличий. Большинство из этих отличий не принципиальные, а произошли потому как так получилось при реализации.
Можно. Сейчас это просто косяк реализации. Хотя, по моему мнению, лучше энумы в дженерик-типах не объявлять. Это плохая практика.
X>По теме соглашусь с коллегами — что-то ранее MSVS 2015 в поддержке не нуждается.
ОК, тогда как она выйдет перейдем на ее и будем ориентироваться на 2015+. Код, естественно, можно будет компилировать под любую платформу, а вот плагины только под 2015+.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
>> В 4.5 есть разные полезные вещи вроде ImmutableArray. Интеграцию мы уже перевели на 4.5+, т.е. в расчете на VS 2013 и старше. А в релизе, скорее всего, будем рассчитать уже на 2015 студию.
Здравствуйте, VladD2, Вы писали:
>Пока что мы планируем для этого использовать CCI Metedata. Если будут проблемы, будем ковырять Розлин (он на отпочковался от CCI Metedata).
Посмотрите в сторону dnlib. Это такой Cecil на стероидах, на его основе сейчас работают de4dot, ConfuserEx и ILRepack.
Если нам не помогут, то мы тоже никого не пощадим.
