В реальности я надеюсь, что команда Н2 закончит проект и ее уволят... - Nemerle

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

R>>Звучит, конечно, здорово, но сама Микрософт уже сколько лет доделывает Розлин. Не кажется, что объем работы для Н2 на порядок больше? Или расчет идет на то, что Н2 будет простой, как и сама базовая Немерля, а шарп на ней будет немерянно легче имплементировать, чем на самом шарпе?
VD>Розлин — это ~~закат солнца вручную~~ ручная реализация менеджед-компиляторов C# и VB, а так же движок для IDE написанные на тех самых C# и VB.
К розлину уже давно появились средства типа генерации C#-кода который генерирует (? извиняюсь давно видел — могу чуть-чуть сбрехать) AST того же шарпа. Выхлоп этой тулзы превышает раза в 3-4 размер исходного кода. Даже в N1 эта проблема решена квазицитатами и, положа руку на сердце — я бы до квазицитат низашобывжизнисамбынидогадалсябы, но это реально очень красивое решение. Тем не менее у них (МС), насколько я понимаю, всё это остаётся на том самом уровне, где их фреймворк работает, но жизни нихрена не облегчает. Сгенерировать аспекты/классы? Да проще было и без Roslyn взять Mono.Cecil и переписать (rewrite) сборку, нежели трахаться с ихним избортением. Самое главное что это и сейчас остаётся правдой. Когда не было средств типа Cecil/Cci/IKVM — может это и было проблемой, но сейчас — как раз отнюдь никак не проблема.
А N1 уже предлагает совершенно иной подход. Проблемы есть? Есть конечно, но кто ищет — их находит, даже если взглянуть по этому форуму, хотя этот форум скорее для гиков, которые пытаются доработать компилятор.

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

(ASP.NET WebStack и т.п., да, кстате — почему git? — неужели их расфуфыристая TFS — так плохо подходит?)).

А с Roslyn, скорее всего многие получат фишки кторые ждали, но ещё больше обломаются, когда не найдёт того, чего ждали.

VD>Н2 — это мета-средство для создания того же самого для (потенциально) любого языка. Задача сложная, но дающая ряд преимуществ. Создав однажды мета-средство мы резко упрощаем дальнейшую работу. Ну, и пишем мы это все на не C# и VB, а на Немереле и на самом Н2, что резко поднимает производительность. Хотя не скрою, объем работы огромный и нам будет не просто сделать все в срок. Но мы постараемся.

Еще хочется, пожелать, в зависимости от позиционирования языка — перестать быть зависимым от ненужного. Например использование лямбд на аргументе Predicate<T> — тянет за собой !!!ненужную!!! за собой Nemerle.dll. Если язык хочет быть под .NET — то он его должен утилизировать по полной. А именно, то, что я случайно увидел, навроде открытия нэйспэйсов по умолчанию и типа Some — это ересь, за которую рубить рубить рубить надо нафиг, с какого вообще что-то открывать по дефолту, а если я как раз нехочу этого? А вообще — я хотел сделать проект .NET 2.0 only. Конечно, никто не мешает, не использовать лишнее и референс не попадёт — но — это дурость несусветная, а если удалить референс — у интеграции крыша едет. Незачем на каждую лямбду вместо метода городить отдельный класс, с телом лямбды. Удобно для компиляции? Пусть так. Удобно для пользователей? Отнюдь — этот Function<XXXX> там вообще нафиг не впал, и я не думаю, что кто-нибуль адекватно сможет его объяснить. Стоит вспомнить мой тест, как только я переписал на X -> Y, вместо Func[X,Y] — скорость компиляции его упала раза в 3.

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

Но, имхо — будет N2 — будут видны планы — будет видно куда двигаться.
Хотите больше пользователей — никаких нахрен зависимостей от Nemerle.dll, по максимуму.
Хотите больше пользователей — дайте контроль, Reference Assemblies пока ещё никто не отменил. :
Хотите больше пользователей — дайте наконец его юзать по полной, а не с теми "стандартными огрызками", которые, мне например, нафиг не впились, и которые вызывают проблемы. Не открывайте нэймспйэсы сами по себе!!! НАФИГ-НАФИГ!!!! ААААААААААААААААААААА!
Стандартная библиотека должна быть подключена только тогда когда это попросит пользователь. Никакого неявного using System C# не делает. А немерле делает. Ф ТОПКУ!!!
[Record] — нафиг. Это дрэг. А особенно с variant-ом.
Код сгенерированный в итоге — не должен содержать ниаких левых аттрибутов. Не нужно аттрибутов, позволяющих восстановить средства его генерации (это кстати о вариантах — варианты — классы — да одно фигня это всё). Короче хрень получается щас, которая иногда друг с другом конфликтует.

С другой стороы — щас опять кодю на шарпе. Не хватает match. Очень и очень. Ну и многого ещё. Но вот стандартной библиотеки Nemerle — как раз очень хорошо, что нет. У меня хватает своих нароботок вообще. Some — это вообще бред в N. option — не бред. А вот реализации — бред. Тут уже обсуждали не раз.

Кто знает, — для меня N пока решает очень узкий круг задач, там где я его имел мечты применить — увы не могу — мне нужен unsafe. А там где не хотел — и не надо.

Знаю, что пахнет негативом, это не со зла, наоборот, хочется большего и лучшего. Кому-то мои замечания покажутся глупыми — кому-то нет. Мне в общем-то всё равно, реальность от этого прямо щас никак не изменится.

Просто это реально наболевшие вопросы. И я знаю, что команда RSDN в этом смысле, ни к одной моей претензии не приложила палец, всё конечно же дело в поляках, ну или я буду в это верить.

В любом случае ждём обещанных анонса/отчётов с полей боя о том что нас ждёт в будующем и какую роль в этом всём будет играть N2.
Без этого рассуждения на счет N1 — имхо — безсмысленны.

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

Z>>Значит нужна стабильная ветка в которой правят баги, но не трогают сигнатуры. И master, в котором делают новые фичи и мерджат в него stable.
VD>Что значит "стабильная ветка в которой ... не трогают сигнатуры"?
VD>Почему под такую не проходят релизы? Вот на сегодня есть 1.0 и 1.1. Юзай их. Все что берется из мастера априори не стабильно.
VD>Гарантировать, что не будет изменений невозможно. Если сама Nemerle.dll относительно стабильна, то другие либы — нет. А с ними будет такая же проблема когда кто-то захочет из из нюгета использовать.
Скорее всего так и есть (относительно стабильна). Необходимо сделать из относительно стабильна — полностью стабильна. Это в общем-то общий подход, для тех, у кого жизненный цикл продукта достаточно длинный.
Думаю, что всё что нужно — это необходимо обеспечить, что бы Nemerle.dll's AssemblyVersion были 1.0.0.0, 1.1.0.0, 1.2.0.0, при этом AssemblyFileVersion можно наращивать так как это делается сейчас, в конце концов для более точной информации есть AssemblyInformationalVersion в который можно ложить хоть id коммита.
Но при этом необходимо следить что бы новые сборки "вдруг" ничего не ломали, во-впервые опубликованных контрактах. Следить за этим нужно специально, а не то как бог надушу положит, как это происходит сейчас (в силу отсутствия процесса контроля). Т.е. что бы это сделать по уму — за этим просто нужно специально следить и в общем-то всё. При том уже можно договорится могут ли минорные релизы ломать обратную совместимость. Мне кажется, что могут, и скорее всего больше всего парит, что имея новую версию компилятора с исправленными багами или улучшениями — мы в нагрузку получаем новую версию nemerle.dll, даже в том случае, если на неё эти изменения никакого эффекта не оказывали. Способ использовать только оффициальные билды — способ конечно, но врядли он годится в этом случае, т.к. компилятор далеко не такого качества, как тот же C# — зато и не надо ждать по 3 года, пока корпорация добра почухается.
В общем это моё, возможно ограниченное видение, Ziaw думаю поправит и дополнит.
Хотя это всё что я описал вероятно с нюгетом может и не помочь, но я нюгет глубоко никогда не копал.

Z>>ЕМНИП диагностика будет достаточно внятной, но такого счастья и правда не нужно.
VD>Если мы чего-то не можем гарантировать, то должны быть уверены, что люди не начнут рвать на себе волосы. Так что ты уж раз предлагаешь, то потрудись провести эксперименты и выложи здесь отчет о них. А там уже решим. Может и правда я слишком перестраховываюсь.
Получишь вероятнее всего TypeLoadException для некоторых типов, у кого не сошлись наименования/сигнатуры, но если выполнить вышеописанное — т.е. обеспечить обратную совместимость — то такое если и будет возникать, то крайне редко.

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

WH>Мегафейспалм.

Можно редактировать текст по мере выполнения.
Использовать переменные с одним именем, но разных типов.
Преимуществ дофига. Фактически работа с некорректным кодом.

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

VD>Что значит "стабильная ветка в которой ... не трогают сигнатуры"?

Я даже не знаю как это объяснить, какое слово непонятно? Ветка?

VD>Почему под такую не проходят релизы? Вот на сегодня есть 1.0 и 1.1. Юзай их. Все что берется из мастера априори не стабильно.

К примеру Nemerle.Web не собирается релизом 1.1 (ICE) Чтобы ее собрать приходится ставить себе ночной билд. Поэтому, к примеру, на сервере rsdn не получается установить стабильную версию. Хорошо, что сам немерл, который там собирается не использует инсталяцию. А что делать, если мне вдруг захочется собирать nrails? Бутстрапить их?

VD>Гарантировать, что не будет изменений невозможно. Если сама Nemerle.dll относительно стабильна, то другие либы — нет. А с ними будет такая же проблема когда кто-то захочет из из нюгета использовать.

Проблема того, что все либы немерла приходится тащить вместе с компилятором. По уму они должны лежать в nuget и быть зависимы от nemerle runtime 1.0 или 1.1. Сам nemerle надо положить в chockolate (это nuget package для бинарников), а интеграцию в галерею. Тогда надобность в инсталяторе отпадет, как и отпадут зависимости от либ, идущих с компилятором.

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

Еще появляется проблема с интеграцией. Она тоже должна билдить конкретным компилятором, а не тем которым она собрана.

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

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

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

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

Здравствуйте, <Аноним>, Вы писали:

А>Про breaking changes речь не идёт. Просто о проблемах статической системы типов при появлении новых версий, если требуется обеспечить работу старых.
Нет таких проблем. Ты их придумал.
Ибо сколько я видел IDocument2 и компанию они все наследовались от IDocument.
А если говорить не про кривущий СОМ, а про несколько более прямой .НЕТ то там даже наследников создавать не нужно.
Просто добавляем методы и вперед.
Если клиент не использует новые методы, то он и не заметит что что-то поменялось.

А>Кстати, ещё в качестве примера пришёл в голову javascript. Учитывая, что в каждом браузере есть свои расширения и они постоянно развиваются (забудем даже про несооответствие стандартам),
Хуже примера ты придумать не мог.
Ибо в результате любой код на нем нужно тестировать во ВСЕХ браузерах.
Либо делать компилятор нормального языка в жабаскрипт чтобы он все проблемы всех браузеров обходил.

А>статическим он, мне кажется, не мог бы быть принципиально.
Мог.
Жаба работает. .НЕТ тоже.
И проблем бы было намного меньше.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

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

WH>>>В Н2 будет только 3 стадии.
WH>>>1)Парсинг.
WH>>>2)Типизация.
WH>>>3)Кодогенерация.
А>>Зачем их строго разделять?
WH>Ну, попробуй не разделить

Разборка текста зависит от типа объекта. Фактически я не представляю как их можно в рамках Н2 разделить.

Здравствуйте, Аноним, Вы писали:

А>Не думаю,что Н2 будет открыт и доступен.

Ты не думай, ты стену ищи. Ну ты понял...

PS
Немерлю даже я уже стал использовать "немного в продакшене".

Правда, шэф об этом не знает...

Но я стараюсь, чтобы код был супир!

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

ВД>>>>>Н1 будет жить и развиваться до тех пор пока он кому-то нужен.

Да я по ходу ступил и прочитал "до тех пор пока" как "until".

DR>При чём тут "продакшин" вообще не ясно.

Другими словами как я это переварил, до тех пор пока серъезного продакшина нет, немерля может расти и развиватся. Как она станет кому-то хужна — детство окончено и начинаются трудовые будни. Как у си-плюс-плюса, си-шарпа и прочих взрослых.

И уже с опытом Н2 они начнут делать Н3.

Не думаю,что Н2 будет открыт и доступен.

14.08.12 15:42: Перенесено из 'Nemerle'

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

ВД>>>>Н1 будет жить и развиваться до тех пор пока он кому-то нужен.

R>буквально можно прочитать как "как только Немерля уйдет в серъезный продакшин, развитие заканчивается".

Не вижу как это можно прочитать так образом.

"Кому-то нужен Немерле" ⇒ "Немерле живёт" ∧ "Немерле разивается"

экивалентно:

"Немерле умер" 𝗏 "Немерле заморожен" ⇒ "Немерле никому не нужен"

При чём тут "продакшин" вообще не ясно.

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

F> Открой для себя WebIDL и обнаруж, что исключительно все интерфейсы — статические, и легко вписываются в систему типов .NET. JS — лиш биндинг к этим интерфейсам и их реализации в движках. В WebKit эти биндинги кстати генерируются автоматически по тем же WebIDL.
Вот допустим, есть браузер X версии 8.0 и есть пусть даже он же, но версии 9.0. И в версии 9.0 появился прикольный метод blink. как в статической системе типов, написть код, который использовал бы его, но продолжал работать в версии 8.0 пусть и не так красиво?

Здравствуйте, <Аноним>, Вы писали:

А>Кто контролирует API при таком подходе?
Какое отношение API имеет к системе типов.
Правильно. Никакое.

А>кто из производителей браузеров согласится, чтобы ему диктовали API?
А что http://www.w3.org/ уже отменили?

А>Кто из разработчиков захочет пользоваться лишь усреднённым минимумом функциональности?
Все кто хочет, чтобы их сайт адекватно отображался в разных браузерх именно этим и занимаются.
Сам этим маленько занимался.
Проклял их всех.
Ибо во всех браузерах всё работает по-разному.
Полагаться можно только на фичи которым лет 10.

А>И самое главное, как это поможет коду использовать по максимуму новые возможности и работать в старых браузерах?
Эти сказки ты рассказывай тому, кто ни разу не пытался сверстать страничку, которая одинаково отображается в разных браузерах.
Я пытался.

А>Система типов потенциально меняется,
Зачем системе типов меняться?

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Аноним, Вы писали:

А>Кто контролирует API при таком подходе? кто из производителей браузеров согласится чтобы ему диктовали API?

Все. А вот пример диктатора.

А>Кто из разработчиков захочет пользоваться лишь усреднённым минимумом функциональности? И самое главное, как это поможет коду использовать по максимуму новые возможности и работать в старых браузерах?

Единственный способ придуманный для борьбы с разрозненными API — это создание оберток. И совершенно по фиг на чем делать обертки, на динамике или на статике. Какой-нить jquery без проблем мог бы оперировать DOM-ом через 5 разных типизированных API. Главное чтобы можно было добиться требуемой функциональности.

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

F> Еще хочется, пожелать, в зависимости от позиционирования языка — перестать быть зависимым от ненужного. Например использование лямбд на аргументе Predicate<T> — тянет за собой !!!ненужную!!! за собой Nemerle.dll.
А вот F# тоже не тянет ненужное ?

F> Если язык хочет быть под .NET — то он его должен утилизировать по полной. А именно, то, что я случайно увидел, навроде открытия нэйспэйсов по умолчанию и типа Some — это ересь, за которую рубить рубить рубить надо нафиг, с какого вообще что-то открывать по дефолту, а если я как раз нехочу этого?
Можно продумать как это отменить, а чем конкретно это вам мешает ?

F> А вообще — я хотел сделать проект .NET 2.0 only. Конечно, никто не мешает, не использовать лишнее и референс не попадёт — но — это дурость несусветная, а если удалить референс — у интеграции крыша едет.
А что там мешает сделать .Net 2.0 only ?

F> Незачем на каждую лямбду вместо метода городить отдельный класс, с телом лямбды. Удобно для компиляции? Пусть так. Удобно для пользователей? Отнюдь — этот Function<XXXX> там вообще нафиг не впал, и я не думаю, что кто-нибуль адекватно сможет его объяснить.
Ну к примеру:

using System.Console;

def a = x => x + 1;
def b = y => y * 2;

def c = a >> b <| 4;
WriteLine(c);

F> Стоит вспомнить мой тест, как только я переписал на X -> Y, вместо Func[X,Y] — скорость компиляции его упала раза в 3.

Это стоит записать в разряд недоработок, и исправить

C# компилятор тоже создает класс для лямбды.

F> В общем — N — хороший язык, действительно решает кучу задач. Но и детских болезней у него капец как много. От глупого IL кода, с теми же def — каждый следующий def что-то не собирается переиспользовать слот вообще — так и в целом встречались.

Делов то, подправьте реализацию и будет вам счастье

F> skip
F> Стандартная библиотека должна быть подключена только тогда когда это попросит пользователь. Никакого неявного using System C# не делает. А немерле делает. Ф ТОПКУ!!!
Код компилятора открыт для улучшений.

F> [Record] — нафиг. Это дрэг. А особенно с variant-ом.
Не нравится Record , не пользуйтесь. Никто вас не обязывает.

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

F> С другой стороы — щас опять кодю на шарпе. Не хватает match. Очень и очень. Ну и многого ещё. Но вот стандартной библиотеки Nemerle — как раз очень хорошо, что нет. У меня хватает своих нароботок вообще. Some — это вообще бред в N. option — не бред. А вот реализации — бред. Тут уже обсуждали не раз.
Давайте вы будете писать конкретные проблемы.
Чем не нравится option ?
Между прочим в том же F# открыто пространство имен с option, Some, None. Но это вас не смущает.

F> Кто знает, — для меня N пока решает очень узкий круг задач, там где я его имел мечты применить — увы не могу — мне нужен unsafe. А там где не хотел — и не надо.
В каком виде нужен unsafe ?
На текущий момент несколько вариантов.
1. Использовать C#.
2. Использовать Masrhal и обернуть в макрос для удобства.
3. Использовать C++/CLI .

F> Знаю, что пахнет негативом, это не со зла, наоборот, хочется большего и лучшего. Кому-то мои замечания покажутся глупыми — кому-то нет.
Да, есть много мелких недоработок.
Но если вы заинтересованны в развитии, то их можно устранить.
Код компилятора открыт, каждый может добавить то, что ему недостает и исправит недостатки которые ему мешают.
Вот я не поленился и добавил пару фич. Это не так сложно как кажется.

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

Я то определился. Задача сделать сборку без зависимостей, ничего кроме mscorlib/System ей не нужно. Это требование, можешь с ним не соглашаться, но оно от этого никуда не денется.

В этой ситуации немерл ничем не может помочь, исключительно потому что так реализован.

Если не использовать каких-то особых фишек — то и зависимость не появляется.

Но без лямбд — жить тяжело, а шарп справляется с любыми лямбдами, — потому что это просто возможность генерировать тело метода на основе известного типа делегата.
В N всё тоже самое, только насильно притянут свой Function, который разумеется шире в возможностях. Тем не менее при вызове метода, например, Where передавая туда инлайн лямбду — толку от этого Function никакого нет, ни одна из его возможностей не будет задействована. Т.е. если очень захотеть — то в этом случае вполне можно генерировать всё тот же класс, но не наследовать его от Function, заодно кешируя в нём целевой делегат, а не просто себя.
Из-за чего собственно и происходит лишнее создание делегата, если это не Function, что как бы тоже не шибко хорошо, хотя терпимо, ибо с замыканиями его всё равно создавать.

Но опять же — шарп создаёт один класс на замыкание и лямбды. В N — их уже два. Т.е. вызов лямбды с замыканием стоит на один объект дороже, и их нужно уже не два, а три, или в случае собственного функционального типа — их всё ещё нужно два, но мог бы быть и один, что было бы явно покруче шарпа.

Но судя по всему это конечно же ерунда, спички и игрушки.

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

Z>>Понимаешь, тут нет решений без недостатков. Влад может сколько угодно говорить, что никого не парит зависимость от Nemerle.dll, но меня парит. Просто потому, что эта зависимость на сугубо конкретную версию Nemerle.dll.
WH>А что в своей сборке нельзя сделать ссылку не на конкретную версию?

В скомпилированной нельзя. У меня в проекте миграции на nemerle. Макросы и либа для них подключаются в скомпилированном виде. Это все должно собираться (и собирается) без установки немерла, мигратор сам компилирует миграции.

WH>Мы тут занимаемся хардкорным макросостроением с бутстрапингом.
WH>И проблем с разными версиями немерла у разных разработчиков не имеем.
WH>Что мы делаем не так?

У вас весь проект в исходниках, нет зависимостей от бинарников собранных немерлом. Соответственно таких конфликтов быть не может.

Влад пытается доказать, что я один такой (да и ты сейчас намекаешь), но вряд-ли кто-то будет утверждать, что невозможность сделать nuget package является мелкой проблемой. Ирония в том, что доработки nuget для поддержки немерловых проектов дают возможность подключать только либы написанные на других языках.

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

Z>В скомпилированной нельзя. У меня в проекте миграции на nemerle. Макросы и либа для них подключаются в скомпилированном виде. Это все должно собираться (и собирается) без установки немерла, мигратор сам компилирует миграции.

Мне кажется лучше это показать более наглядно.

Как я понял имеем зависимость:
Y.dll <- X.dll <- Nemerle.dll

При чем X.dll распространяется исключительно в бинарном виде, т.е. ему нужна определенная версия Nemerle.dll.
А значит даже указав SpecificVersion False для X.dll, мы все равно прибиваемся к конкретной версии Nemerle.dll, потому как повлиять на ссылки X.dll уже не можем.

Правильно ?

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

F> Да я в курсе, но это крайне далеко от того что поддерживает шарп (по крайней мере на момент публикации). В принципе меня это уже никоим образом не парит — код с указателями плавно переплывает в совсем автогенерированный — хоть на IntPtr-ах можно извращаться.

Я ансэйф и готу как раз для генерации более быстрого кода и сделал. Писать это руками я бы не стал. А генерированный код с ними терпеть можно, так как он по модели генерируется и отладки каждой строчки не требует.

В прочем, пока мы используем только готу.

Но в целом — согласен! Генерация кода решает много проблем. В том числе и эту.

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

M>PS
M>Немерлю даже я уже стал использовать "немного в продакшене".

Правда, шэф об этом не знает...

Но я стараюсь, чтобы код был супир!

Если Н2 это отдельный совершенно новый язык, то не слишком ли рискованно именно теперь, когда все разработчики компилятора заняты разработкой нового Н2, начинать что-то делать на старом, отживающим свой век Н1? Никаких обещаний о совместимости Н1 и Н2 я не слышал.

M>PS
M>Немерлю даже я уже стал использовать "немного в продакшене".

Правда, шэф об этом не знает...

Но я стараюсь, чтобы код был супир!
А можно поподробней, как удаётся использовать N с C# проeктами.

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

I>А можно поподробней, как удаётся использовать N с C# проeктами.

С помощью Add Reference?..

А>Если Н2 это отдельный совершенно новый язык, то не слишком ли рискованно именно теперь, когда все разработчики компилятора заняты разработкой нового Н2, начинать что-то делать на старом, отживающим свой век Н1? Никаких обещаний о совместимости Н1 и Н2 я не слышал.

Эх, ии не говори! Везде нашего брата-анонима надурить хотят!

Здравствуйте, Аноним, Вы писали:

А>>Если Н2 это отдельный совершенно новый язык, то не слишком ли рискованно именно теперь, когда все разработчики компилятора заняты разработкой нового Н2, начинать что-то делать на старом, отживающим свой век Н1? Никаких обещаний о совместимости Н1 и Н2 я не слышал.
А>Эх, ии не говори! Везде нашего брата-анонима надурить хотят!

Так никто никого не дурит.
Был задан конкретный вопрос, ответа на который пока не последовало.

А>Так никто никого не дурит.
А>Был задан конкретный вопрос, ответа на который пока не последовало.

Да уже просто 10 раз отвечалось, вот и вломину было. N2 пишется на N1, и синтаксис N1 будет повторён одним из первых.

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

_>Да уже просто 10 раз отвечалось, вот и вломину было. N2 пишется на N1, и синтаксис N1 будет повторён одним из первых.

Ну это я знаю. Это означает, что Н1 будет поддерживаться работоспособным, пока пишется Н1. Причем будет ли синтаксис Н2 при этом совпадать с Н1 — неясно.
Только после этого сделают бутстрепинг, т.е. он будет заново переписан, но уже на Н2.
И тогда Н1 вообще останется за бортом, в то время как будет готов Н2, с совершенно другим синтаксисом и плюшками?

Здравствуйте, Аноним, Вы писали:

А>Если Н2 это отдельный совершенно новый язык, то не слишком ли рискованно именно теперь, когда все разработчики компилятора заняты разработкой нового Н2, начинать что-то делать на старом, отживающим свой век Н1? Никаких обещаний о совместимости Н1 и Н2 я не слышал.

Более того, Н2 это даже не язык программирования общего назначения. Н2 это языковый фрэймворк (ну, или специальный язык для создания других языков). Так что с Н1 (под которым обычно понимается немерл) они даже не конкуренты.

Н1 будет жить и развиваться до тех пор пока он кому-то нужен.

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

VD>Н1 будет жить и развиваться до тех пор пока он кому-то нужен.

Ха, нравится мне эта фраза. А как кому-то понадобится, развитие прийдется прекратить?

Здравствуйте, Аноним, Вы писали:

А>И тогда Н1 вообще останется за бортом, в то время как будет готов Н2, с совершенно другим синтаксисом и плюшками?
уже стопятсот раз объясняли
-Н2 нужен для РАСШИРЕНИЯ гибкости немерли
-Н2(основной язык) будет НАДМНОЖЕСТВОМ немерли, т.е ЯЗЫК будет с большой вероятностью 100% совместим
-макросы для Н2 пиши какими хочешь => использование макросов(например "for") будет с большой вероятностью 100% совместимо
-система метрапрограммирования будет абсолютно новой => старые МАКРОСЫ большой вероятностью НАДО БУДЕТ ПЕРЕПИСАТЬ

Здравствуйте, Аноним, Вы писали:

А>Если Н2 это отдельный совершенно новый язык...

Не совсем. Как я понял из многих сообщений, Н2 будет новым АРХИТЕКТУРНО. Но будет максимально совместимым с Н1. Да и какой смысл менять то, к чему люди годами привыкали?? Разве что выкинут костылеобразное arr.[3] (обязательную точку).

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

I>А можно поподробней, как удаётся использовать N с C# проeктами.

Так я ничего выкрутасного не делаю! Классы-Документы лежат в C# проекте (DLL), он загружается немерлёй, рефлектится вдоль и поперёк и на выходе получаем другой C# проект, в котором построен UI для манипуляции доками. Вот эта генерация других сорсов делается элегантным способом $-строками — намного очевиднее сишарповых стрингбилдеров и форматтеров. Возможно, T4 тоже было бы решением, но его использование было бы угловатым — он больше подходит для задач 1 вход — 1 выход.

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

R>Ха, нравится мне эта фраза. А как кому-то понадобится, развитие прийдется прекратить?

С чего бы это?

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

C>С чего бы это?

Я имел ввиду предложение

ВД>>>Н1 будет жить и развиваться до тех пор пока он кому-то нужен.

буквально можно прочитать как "как только Немерля уйдет в серъезный продакшин, развитие заканчивается". Смешно, но это реалия для кучи языков и фрэймворков, к сожалению. Хотелось бы чтоб немерля побыла в "детстве" подольше... И язык, и особенно синтакс макросов + стандартная библиотека. Ломать не строить. Хотя в кошмарах всплывает .НЕТ 1.1 в 2008 году, когда в 2.0 несловленное исключение из фонового потока (background thread) начало вдруг убивать все на своём пути и, в результате, вся индустрия пару лет занималась наследованием CollectionBase.

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

R>Хотелось бы чтоб немерля побыла в "детстве" подольше... И язык, и особенно синтакс макросов + стандартная библиотека. Ломать не строить.

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

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

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

R>Другими словами как я это переварил, до тех пор пока серъезного продакшина нет, немерля может расти и развиватся. Как она станет кому-то хужна — детство окончено и начинаются трудовые будни. Как у си-плюс-плюса, си-шарпа и прочих взрослых.

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

Именно эту особенность мы и хотим развить в Н2.

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

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

VD>Н2 это технологическая основа для создания расширяемых языков. Причем на его основе можно будет, относительно не сложно, реализовать не только улучшенную версию Немерла, но и сделать расширяемые версии других языков (например, шарпа).

Звучит, конечно, здорово, но сама Микрософт уже сколько лет доделывает Розлин. Не кажется, что объем работы для Н2 на порядок больше? Или расчет идет на то, что Н2 будет простой, как и сама базовая Немерля, а шарп на ней будет немерянно легче имплементировать, чем на самом шарпе?

Но, ИМХО, все языки имеют пересечения только с академической точки зрения. Да, концепции типов, переменных, наследования и т.п. довольно похожи друг на друга. Но имплементация компиляторов абсолютно другая.

Например шарп вначале определяется с типами и их членами по всему проэкту, а уже затем парсит код внутри методов. В то время как Си++ парсает всё подряд: хочешь вызвать функцию имплементированую позже, будь добр, задекларируй её заранее.

Хуже с темплейтами, где полностю отсутствует типизация.

А макросы Си/Си++, вообще, ломают все рамки со скобками. Можно, конечно остановится, сказав: "это должно просто обрабатываться на уровне глупого препроцессора". Но юзера тут же забухтят, — "А где мой интеллисенс? Да мне в Vim 15 лет назад лучше кодировалось!".

Та же ситуация в JavaScript и SQL с их eval-фичами, или использованием их же как встроеных (embedded™) языков. Там после включения какой-нибудь eval-напичканой библиотечки нужно подрубать искуственный интелект, способный бороться с Проблемой Остановки. Микрософт, вроде бы, что-то недавно наклепали в Студии недавно на эту тему, чем очень гордились — с деталямия я не знаком, к сожалению.

Промолчу про саму Немерлю, которая хоть и упрощена до нельзя, но стадий компиляции — непочатый край.

Я веду к тому, что весь этот зоопарк не просто разные способы изобразить одно и то же. Может еще Си-шарп, VB.NET, и Жаву можно к общему знаменателю подогнать. Добавь чего-то "нестандартное" и сложность растет экспоненциально.

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

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

I>>А можно поподробней, как удаётся использовать N с C# проeктами.

M>Так я ничего выкрутасного не делаю! Классы-Документы лежат в C# проекте (DLL), он загружается немерлёй, рефлектится вдоль и поперёк и на выходе получаем другой C# проект, в котором построен UI для манипуляции доками. Вот эта генерация других сорсов делается элегантным способом $-строками — намного очевиднее сишарповых стрингбилдеров и форматтеров. Возможно, T4 тоже было бы решением, но его использование было бы угловатым — он больше подходит для задач 1 вход — 1 выход.

Интересная идея. К немерлю только присматриваюсь, думаю было бы и другим интересно посмотреть на тестовый проект как это делаете. Может сделаете маленький пример и зальёте его куда-то.

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

R>Звучит, конечно, здорово, но сама Микрософт уже сколько лет доделывает Розлин.
В майкрософт очень не правильно подходят к разработке.
Да и конечный продукт у них будет мягко говоря не о том.

R>Не кажется, что объем работы для Н2 на порядок больше?
Скорее, на порядок меньше.
Но сложнее. Ибо алгоритмы придумывать надо.

R>Или расчет идет на то, что Н2 будет простой, как и сама базовая Немерля, а шарп на ней будет немерянно легче имплементировать, чем на самом шарпе?
Н2 это не язык общего назначения.
Это язык для описания языков. И себя в том числе.
Часть Н2 уже есть. И он уже частично написан сам на себе.
Дальше будет больше.

R>Но, ИМХО, все языки имеют пересечения только с академической точки зрения. Да, концепции типов, переменных, наследования и т.п. довольно похожи друг на друга. Но имплементация компиляторов абсолютно другая.
Это по тому, что руками. А если реализацию компилятора генерировать, то там все будет очень похоже.

R>Например шарп вначале определяется с типами и их членами по всему проэкту, а уже затем парсит код внутри методов. В то время как Си++ парсает всё подряд: хочешь вызвать функцию имплементированую позже, будь добр, задекларируй её заранее.
Тут всё намного проще, чем кажется.

R>Хуже с темплейтами, где полностю отсутствует типизация.
Тут ты не прав.
Она хоть и не полная, но она там есть.
То, что обычно разработчики компиляторов ее не осиливают, не значит что, её там нет по стандарту.

R>А макросы Си/Си++, вообще, ломают все рамки со скобками. Можно, конечно остановится, сказав: "это должно просто обрабатываться на уровне глупого препроцессора". Но юзера тут же забухтят, — "А где мой интеллисенс? Да мне в Vim 15 лет назад лучше кодировалось!".
Это должно обрабатываться на уровне препроцессора.
Вот только интелесенсу оно не мешает. Если правильно делать.

R>Та же ситуация в JavaScript и SQL с их eval-фичами, или использованием их же как встроеных (embedded™) языков.
Динамически типизированные языки не нужны.
Вообще.

Они не ловят ошибки. Они тормозят. Для них нельзя сделать нормальный интелисенс.

R>Промолчу про саму Немерлю, которая хоть и упрощена до нельзя, но стадий компиляции — непочатый край.
Тут вообще никаких проблем с интелесенсом.
Хотя есть проблемы с тем, чтобы под это дело писать макросы. Эти стадии мне весь мозг уже съели.

В Н2 будет только 3 стадии.
1)Парсинг.
2)Типизация.
3)Кодогенерация.

R>Я веду к тому, что весь этот зоопарк не просто разные способы изобразить одно и то же. Может еще Си-шарп, VB.NET, и Жаву можно к общему знаменателю подогнать. Добавь чего-то "нестандартное" и сложность растет экспоненциально.
Линейно. Я на эту тему очень много думал и изучал.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

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

VD>>Н2 это технологическая основа для создания расширяемых языков. Причем на его основе можно будет, относительно не сложно, реализовать не только улучшенную версию Немерла, но и сделать расширяемые версии других языков (например, шарпа).

R>Звучит, конечно, здорово, но сама Микрософт уже сколько лет доделывает Розлин. Не кажется, что объем работы для Н2 на порядок больше? Или расчет идет на то, что Н2 будет простой, как и сама базовая Немерля, а шарп на ней будет немерянно легче имплементировать, чем на самом шарпе?

Roslyn это Nemerle без поддержки удобным языком. То есть получается компилятор, который позволяет встраиваться в разные стадии компиляции, но не имеет языковых средств, типа макросов для удобного применения. Так же отсутствует паттерн матчинг, что делает работу с AST совершенно зубодробительным процессом. Про синтаксические расширения я промолчу, до них майкрософту еще далеко.

Шарп, как он имплементирован сейчас, будет совсем не сложно сделать (то есть транслятор в Nemerle и потом компиляция по его правилам). Другое дело, что спецификация шарпа есть, а немерла нет. И повторить спецификацию шарпа будет не то, что бы сложно, просто очень объемно. JB имеет такие ресурсы, вопрос только в целесообразности.

R>Но, ИМХО, все языки имеют пересечения только с академической точки зрения. Да, концепции типов, переменных, наследования и т.п. довольно похожи друг на друга. Но имплементация компиляторов абсолютно другая.

R>Например шарп вначале определяется с типами и их членами по всему проэкту, а уже затем парсит код внутри методов. В то время как Си++ парсает всё подряд: хочешь вызвать функцию имплементированую позже, будь добр, задекларируй её заранее.

У вас очень поверхностное представление о компиляторах.

R>Хуже с темплейтами, где полностю отсутствует типизация.

R>А макросы Си/Си++, вообще, ломают все рамки со скобками. Можно, конечно остановится, сказав: "это должно просто обрабатываться на уровне глупого препроцессора". Но юзера тут же забухтят, — "А где мой интеллисенс? Да мне в Vim 15 лет назад лучше кодировалось!".

Препроцессор естественно нужен (не в темплейтах конечно), а скорость это вопросы оптимизации. Никто не говорил, что супер сложные задачи превратятся в элементарные, они станут просто сложными. Нормальный сенс в С++ получить очень непросто и эту сложность никуда не денешь.

R>Та же ситуация в JavaScript и SQL с их eval-фичами, или использованием их же как встроеных (embedded™) языков. Там после включения какой-нибудь eval-напичканой библиотечки нужно подрубать искуственный интелект, способный бороться с Проблемой Остановки. Микрософт, вроде бы, что-то недавно наклепали в Студии недавно на эту тему, чем очень гордились — с деталямия я не знаком, к сожалению.

Не понял про JS, какие проблемы распарсить eval'ы?

R>Промолчу про саму Немерлю, которая хоть и упрощена до нельзя, но стадий компиляции — непочатый край.

Скажу по секрету, эти стадии в похожем виде есть во всех компиляторах. Просто в Nemerle открыто API для них.

R>Я веду к тому, что весь этот зоопарк не просто разные способы изобразить одно и то же. Может еще Си-шарп, VB.NET, и Жаву можно к общему знаменателю подогнать. Добавь чего-то "нестандартное" и сложность растет экспоненциально.

Это просто инструмент. Применить его к одним языкам будет просто, к другим сложнее. Для одних будет достаточно декларативно задать грамматику, для других придется добавлять препроцессор, для третьих переписывать механизм типизации с нуля, для многих придется писать отдельные бэкенды. Но это все может стать стандартом, как в свое время стали lex&yacc, только еще и для IDE.

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

Z>Roslyn это Nemerle без поддержки удобным языком. То есть получается компилятор, который позволяет встраиваться в разные стадии компиляции, но не имеет языковых средств, типа макросов для удобного применения. Так же отсутствует паттерн матчинг, что делает работу с AST совершенно зубодробительным процессом. Про синтаксические расширения я промолчу, до них майкрософту еще далеко.
Рослин это вообще не о том.
Росли это IDE и компилятор для двух конкретных языков.
Метапрограммирование там сайдэффект. Его никто специально не делал. Ну и получилось то что получилось.

Z>Не понял про JS, какие проблемы распарсить eval'ы?
Такие что я любую IDE для динамически типизированного языка несколькими строками кода могу запутать.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

R>>Не кажется, что объем работы для Н2 на порядок больше?
WH>Скорее, на порядок меньше.
WH>Но сложнее. Ибо алгоритмы придумывать надо.
Работы намного меньше так какое надо разделять стадии искусствено

WH>Динамически типизированные языки не нужны.
WH>Вообще.

WH>Они не ловят ошибки. Они тормозят. Для них нельзя сделать нормальный интелисенс.
Часто простора написания перевешивает все эти плюсы.

WH>Хотя есть проблемы с тем, чтобы под это дело писать макросы. Эти стадии мне весь мозг уже съели.

WH>В Н2 будет только 3 стадии.
WH>1)Парсинг.
WH>2)Типизация.
WH>3)Кодогенерация.
Зачем их строго разделять?
WH>Линейно. Я на эту тему очень много думал и изучал.
Вряд ли линейно, Просто если у экспоненты маленький коэффициент то такая зависимость станет видна только на неимоверно больших программах.

Здравствуйте, <Аноним>, Вы писали:

А>Работы намного меньше так какое надо разделять стадии искусствено
Не смог распарсить предложение.

WH>>Они не ловят ошибки. Они тормозят. Для них нельзя сделать нормальный интелисенс.
А>Часто простора написания перевешивает все эти плюсы.
Это, мягко говоря сказки.
Я уже много лет прошу пример, где бы код на динамически типизированном языке был проще.
Неважно насколько любители динамики хотели показать круть динамики, за все эти годы не было ни одного примера, который бы не сводится к "мне так хочется".

WH>>В Н2 будет только 3 стадии.
WH>>1)Парсинг.
WH>>2)Типизация.
WH>>3)Кодогенерация.
А>Зачем их строго разделять?
Ну, попробуй не разделить

А>Вряд ли линейно, Просто если у экспоненты маленький коэффициент то такая зависимость станет видна только на неимоверно больших программах.
Не надо выдумывать экспоненту там, где её нет.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, <Аноним>, Вы писали:

WH>>Неважно насколько любители динамики хотели показать круть динамики, за все эти годы не было ни одного примера, который бы не сводится к "мне так хочется".
А>Не надо объявлять переменные.
Мегафейспалм.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

Возьмём например продукт типа Excel, который предоставляет интерфейс IDocument, который содержит экзмепляры ISpreadsheet, которые содержат ICell и т.д. И вот появляется версия 2.0 в которой добавилась новая функциональность в компоненты и появлись расширенные интерфейсы — IDocument2, ISpreadsheet2 и прочие. В строго типизировнном мире сразу возникают проблемы — IDocument.GetSpreadsheet возвращает ISpreadsheet, IDocument2.GetSpreadsheet — ISpreadsheet2 — теперь дублировать кучу методов в реализации? а когда появится версия 3? Какой-нибудь ISpreadsheet.MergeCells будет хотеть не ICellRange,а ICellRange2 — писать перегрузки под все типы?

Здравствуйте, Аноним, Вы писали:

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

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

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

F>Здравствуйте, Аноним, Вы писали:

F>Вовсе не обязательно плодить новые интерфейсы, если они только лишь расширяются, по крайней мере в мире .NET.
Можно соорудить сборку 2.0, но интерфейсы версии 1.0 должны работать, и интерфейс из сборки 2.0 как бы не равен интерфейсу из сборки 1.0 даже если у них и сохранено название.

F>Кроме того, если уж и случаются breaking changes — можно и перекомпилировать клиентский код.

Про breaking changes речь не идёт. Просто о проблемах статической системы типов при появлении новых версий, если требуется обеспечить работу старых.

Кстати, ещё в качестве примера пришёл в голову javascript. Учитывая, что в каждом браузере есть свои расширения и они постоянно развиваются (забудем даже про несооответствие стандартам), статическим он, мне кажется, не мог бы быть принципиально.

Здравствуйте, Аноним, Вы писали:

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

Реально у динамики есть только два преимущества:
1. Легкость в реализации полиморфизма (он сам собой получается).
2. Интерактивность разработки.

Оба пункта достижимы и в статике, но их значительно сложнее реализовать.

WH>>>>В Н2 будет только 3 стадии.
WH>>>>1)Парсинг.
WH>>>>2)Типизация.
WH>>>>3)Кодогенерация.
А>>>Зачем их строго разделять?
WH>>Ну, попробуй не разделить

А>Разборка текста зависит от типа объекта. Фактически я не представляю как их можно в рамках Н2 разделить.

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

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

WH>Ибо сколько я видел IDocument2 и компанию они все наследовались от IDocument.
Наследовались, но изменение нарпример ICellRange на ICellRange2 требует изменения всех испольюзующих его контрактов, при этом старые контракты должны оставаться актуальными.

WH>Если клиент не использует новые методы, то он и не заметит что что-то поменялось.
У него старая интерфейсная сборка. Вам же не понравится еслм ваше приложение осуществляющее экспорт в эксель 2000 не будет работать с экселем 2001.

А>>Кстати, ещё в качестве примера пришёл в голову javascript. Учитывая, что в каждом браузере есть свои расширения и они постоянно развиваются (забудем даже про несооответствие стандартам),
WH>Хуже примера ты придумать не мог.
WH>Ибо в результате любой код на нем нужно тестировать во ВСЕХ браузерах.
нужно. Я же прекрасно понимаю в чём минусы динамики, но стараюсь назло тебе найти плюсы

WH>Либо делать компилятор нормального языка в жабаскрипт чтобы он все проблемы всех браузеров обходил.
И какая система типов была бы у этого языка? Сейчас конечно стандартизацию вроде как ускорят, но в любом случае реализация каждой новой фичи будет варьироваться во всех браузерах. т.е. именно в динамической развивающейся среде у статики, имхо, начинаются серьёзные проблемы.

Здравствуйте, Аноним, Вы писали:

F>>Вовсе не обязательно плодить новые интерфейсы, если они только лишь расширяются, по крайней мере в мире .NET.
А>Можно соорудить сборку 2.0, но интерфейсы версии 1.0 должны работать, и интерфейс из сборки 2.0 как бы не равен интерфейсу из сборки 1.0 даже если у них и сохранено название.
Это ты придумал, нет такой проблемы.

А>Кстати, ещё в качестве примера пришёл в голову javascript. Учитывая, что в каждом браузере есть свои расширения и они постоянно развиваются (забудем даже про несооответствие стандартам), статическим он, мне кажется, не мог бы быть принципиально.
Открой для себя WebIDL и обнаруж, что исключительно все интерфейсы — статические, и легко вписываются в систему типов .NET. JS — лиш биндинг к этим интерфейсам и их реализации в движках. В WebKit эти биндинги кстати генерируются автоматически по тем же WebIDL.

Здравствуйте, Аноним, Вы писали:

WH>>Ибо сколько я видел IDocument2 и компанию они все наследовались от IDocument.
А>Наследовались, но изменение нарпример ICellRange на ICellRange2 требует изменения всех испольюзующих его контрактов, при этом старые контракты должны оставаться актуальными.
CellRangeImpl имплементит и то и другое. Методам которые работают с CellRangeImpl — глубоко пофиг через какой интерфейс их позвали. Интерфейсы все эти — лиш адаптеры к реальным объектнам. Так, что тут ты преувеличиваешь. Разумеется эти адаптеры в большинстве случаев можно генерировать. Да, это само по себе не даётся, — но и в динамике это тоже само по себе не даётся.

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

F> CellRangeImpl имплементит и то и другое. Методам которые работают с CellRangeImpl — глубоко пофиг через какой интерфейс их позвали.
Речь не о нём, а о том что DocumentImpl теперь должен уметь возвращать как ICellRange так и ICellRange2 и все методы должны принимать как ICellRange, так и ICellRange2 и так для каждого изменившегося типа, для каждой новой версии.

Здравствуйте, <Аноним>, Вы писали:

А>Вот допустим, есть браузер X версии 8.0 и есть пусть даже он же, но версии 9.0. И в версии 9.0 появился прикольный метод blink. как в статической системе типов, написть код, который использовал бы его, но продолжал работать в версии 8.0 пусть и не так красиво?
Тоже что и в случае с динамикой. Сделать интерфейс, который не будет полагаться на этот метод.
Разница в том, что в случае со статикой мне об этом сразу скажет компилятор, а в случае с динамикой код будет молча глючить.
И такое наблюдалось ни раз и ни сто.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, <Аноним>, Вы писали:

WH>>Если клиент не использует новые методы, то он и не заметит что что-то поменялось.
А>У него старая интерфейсная сборка. Вам же не понравится еслм ваше приложение осуществляющее экспорт в эксель 2000 не будет работать с экселем 2001.
Ты опять про СОМ.
В чистом .НЕТ такой проблемы нет. Совсем нет.

WH>>Ибо в результате любой код на нем нужно тестировать во ВСЕХ браузерах.
А>нужно. Я же прекрасно понимаю в чём минусы динамики, но стараюсь назло тебе найти плюсы

Сомневаюсь. Ибо ты тут совсем динамику дискредитируешь. Выдавая ее минусы за плюсы.

А>И какая система типов была бы у этого языка?
Да хоть та же жаба. Все лучше, чем динамический глюкодром.

А>Сейчас конечно стандартизацию вроде как ускорят, но в любом случае реализация каждой новой фичи будет варьироваться во всех браузерах. т.е. именно в динамической развивающейся среде у статики, имхо, начинаются серьёзные проблемы.
И как добавление новых методов относится к типизации?

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Аноним, Вы писали:

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

F>> Открой для себя WebIDL и обнаруж, что исключительно все интерфейсы — статические, и легко вписываются в систему типов .NET. JS — лиш биндинг к этим интерфейсам и их реализации в движках. В WebKit эти биндинги кстати генерируются автоматически по тем же WebIDL.
А>Вот допустим, есть браузер X версии 8.0 и есть пусть даже он же, но версии 9.0. И в версии 9.0 появился прикольный метод blink. как в статической системе типов, написть код, который использовал бы его, но продолжал работать в версии 8.0 пусть и не так красиво?

var browser90 = browser as IBrowser90;
if (browser90 != null) browser90.blink();

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

J>

J>var browser90 = browser as IBrowser90;
J>if (browser90 != null) browser90.blink();
J>

А теперь, допустим версий не две, а десять и браузер не один, а неопределённое количество, которое периодически пополняется. И например есть браузер Y в котором метод тоже реализован, но в версии 15. Как синхронизировать все интерфейсы? и самое главное — чем больше таких кастов тем больше испаряются преимущества статики и проявляются преимущества динамики.

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

А>>И какая система типов была бы у этого языка?
WH>Да хоть та же жаба. Все лучше, чем динамический глюкодром.
Кто контролирует API при таком подходе? кто из производителей браузеров согласится чтобы ему диктовали API? Кто из разработчиков захочет пользоваться лишь усреднённым минимумом функциональности? И самое главное, как это поможет коду использовать по максимуму новые возможности и работать в старых браузерах?

А>>Сейчас конечно стандартизацию вроде как ускорят, но в любом случае реализация каждой новой фичи будет варьироваться во всех браузерах. т.е. именно в динамической развивающейся среде у статики, имхо, начинаются серьёзные проблемы.
WH>И как добавление новых методов относится к типизации?
Система типов потенциально меняется, а среда исполнения может различаться в том числе и не соответствовать ей.

Здравствуйте, Аноним, Вы писали:

А>А теперь, допустим версий не две, а десять и браузер не один, а неопределённое количество, которое периодически пополняется. И например есть браузер Y в котором метод тоже реализован, но в версии 15. Как синхронизировать все интерфейсы? и самое главное — чем больше таких кастов тем больше испаряются преимущества статики и проявляются преимущества динамики.

дык достаточно не по версиям браузеров интерфейсы вводить, а то фичам:

var blinkable = browser as IBlinkable;
if (blinkable != null) blinkable.blink();

теперь неважно в какой версии какого браузера эта фича реализована.

А>А теперь, допустим версий не две, а десять и браузер не один, а неопределённое количество, которое периодически пополняется. И например есть браузер Y в котором метод тоже реализован, но в версии 15. Как синхронизировать все интерфейсы? и самое главное — чем больше таких кастов тем больше испаряются преимущества статики и проявляются преимущества динамики.
может я далек от этой темы, но каким образом тип типизации (статическая/динамическая) связан с тем, что вы пишете? ну какие могут быть преимущества у динамики?

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

J>дык достаточно не по версиям браузеров интерфейсы вводить, а то фичам:
Просто мусье теоретик. И ни разу ни чего не верстал.
Ибо если бы верстал то не стал бы тут разводить треп про, то, что в разных браузерх всё работает.

Я когда в яндексе работал (слава байту не на вёрстке) у верстаков видел список браузеров, в которых сервисы яндкса должны работать. Их там было (включая разные версии) меньше десятка.
И это блин в яндексе. С его относительно бесконечными ресурсами.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

BS>может я далек от этой темы, но каким образом тип типизации (статическая/динамическая) связан с тем, что вы пишете? ну какие могут быть преимущества у динамики?

Тем что в статике требуется полное описание интерфейса и полное описание интерфейса всех параметров всех методов. Если например меняется тип одного из параметров, меняется и интерфейс.

А в динамике можно сказать: я не знаю что ты такое, но верни мне диапазон ячеек, а вот теперь возьми эти ячейки и объедини их. В независимости от полного описания интерфейса, которое может меняться как в с течением времени, так и (как вслучае с браузером), в зависиомости от окружения. В статике же если тип ячейки нарпример изменился и требуется совместимость, то должна быть реализация как новой системы типов, так и старой.

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

WH>Какое отношение API имеет к системе типов.
WH>Правильно. Никакое.
В статике тип должен быть полностью описан. В динамике нет. Т.е. если есть несколько реализаций с небольшими отличиями в интерфейсе в динамике это разруливается сравнительно просто. С точки зрения статики это будут просто разные типы, несмотря на то что они "почти" одинаковы.

WH>А что http://www.w3.org/ уже отменили?
А разве фичи в стандарте появляются не после того, как они реализованы практически всеми, но немного по разному?

А>>И самое главное, как это поможет коду использовать по максимуму новые возможности и работать в старых браузерах?
WH>Эти сказки ты рассказывай тому, кто ни разу не пытался сверстать страничку, которая одинаково отображается в разных браузерах.
WH>Я пытался.
Есть такое, я и не отрицаю.

А>>Система типов потенциально меняется,
WH>Зачем системе типов меняться?
Прогресс. Появляются же новые элементы типа video, соответственно и api будет развиваться. как же без этого.

WH>Вот из-за таких может все браузеры, и работают по-разному.
Тут подумалось, что аналогом в статическом мире в какой-то степени может быть компиляция под nix-ы, где хитрые скрпиты пытаются определить окружение и определить правильно макросы/поправить код так чтобы компиляция прошла. В браузерах примерно тоже самое, но разброда ещё больше, проверка окружения перенесена на клиента (ибо больше некуда) ну и обычно требуется работоспособность даже если часть функционала недоступна.

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

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

Здравствуйте, Аноним, Вы писали:

А>Вот допустим, есть браузер X версии 8.0 и есть пусть даже он же, но версии 9.0. И в версии 9.0 появился прикольный метод blink. как в статической системе типов, написть код, который использовал бы его, но продолжал работать в версии 8.0 пусть и не так красиво?
Слушай, ты не задумывался о динамическом связывании? А?
Когда ты зовёшь Win32 CreateFile, — тебя как-то не парит Windows 95 это или Windows 7. Тоже самое происходит в .NET и в любых других _нормальных_ средах. Если произошло ОЙ, то тогда ОЙ. Я ещё раз повторяю, что динамические языки и статические — абослютно равны перед тем вопросом, что ты поставил. При том статические как раз вводят гораздо больше контроля над происходящим, в аккурат на этапе компиляции, а не у клиента в продакшине.
Возвращаясь к

Речь не о нём, а о том что DocumentImpl теперь должен уметь возвращать как ICellRange так и ICellRange2 и все методы должны принимать как ICellRange, так и ICellRange2 и так для каждого изменившегося типа, для каждой новой версии.

то DocumentImpl работает исключительно CellRangeImpl, ему нет нужны работать с какими-то обобщенными интерфейсами, и возвращать ему их тоже не нужно. Твои ICellRange1/2/3/4/5/10 — есть адаптеры к одной имплементации. Адаптеры вполне в большинстве своём можно генерировать.

Не веришь?

Почитай W3C DOM Level 3/4 specification. Имплементаций DOM — может быть много, а вот выполнить node1.appendChild(node2) возможно только в случае если node2 из той же имплементации (более того, из того же документа), не смотря на то, что обе ноды реализуют один и тот же интерфейс. Интерфейс — это контракт. Интерфейс в стиле современных языков программирования — не описывает его семантику никак, да и врядли сможет. Увы, но да, как раз семантика описывается документом рядом.

Так что то о чём ты говоришь — реально встречающаяся проблема, но ты её явно преувеличиваешь, заодно сюда мешая динамические языки, которые проблему эту не только не решают, а ещё делают хуже. Решение таких проблем — исключительно индивидуально, способ описанный мною — выдуман мною, но вполне жизнеспособен. С другой стороны, если бы я делал свой JS фреймворк (а я делал) — так вот — мне никто не мешает в новой версии переименовать свойство name в displayName — а далее два варианта: а) name — теперь нечто другое б) его вообще не существует. Если будут существовать два интерфейса вроде IItem1/IItem2 — тогда вопросов в статике не будет, а вот в динамике в JS — будут и плачевные.

Здравствуйте, Аноним, Вы писали:

А>Да я совсем не про то что работает, а про то, что при таком разброде невозможно свести всё к статической системе типов. И если даже взять все браузеры и свести сейчас, то через год она опять развалится, потому что каждый вендор наклепает своё.
Невозможно заставить только IE реализовать стандарты — FF и WebKit и о боже Opera! — их реализует в основном без астрономичных нареканий. Вещи которые, извините, всё ещё в working draft — естественно идут с префиксом движка. Ну так это вам не XAML, которых теперь 5 штук, и все разные, причём наглупили в элементарных вещах. А что другого взять с индусятины-теоретиков?

Здравствуйте, Аноним, Вы писали:

А>В статике тип должен быть полностью описан. В динамике нет. Т.е. если есть несколько реализаций с небольшими отличиями в интерфейсе в динамике это разруливается сравнительно просто. С точки зрения статики это будут просто разные типы, несмотря на то что они "почти" одинаковы.

Ты путаешь статику и виды систем типов. В структурной типизации все тоже самое что ты подразумеваешь под динамикой, хотя типизация статическая и строгая.

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

R>Звучит, конечно, здорово, но сама Микрософт уже сколько лет доделывает Розлин. Не кажется, что объем работы для Н2 на порядок больше? Или расчет идет на то, что Н2 будет простой, как и сама базовая Немерля, а шарп на ней будет немерянно легче имплементировать, чем на самом шарпе?

Розлин — это ~~закат солнца вручную~~ ручная реализация менеджед-компиляторов C# и VB, а так же движок для IDE написанные на тех самых C# и VB.

Н2 — это мета-средство для создания того же самого для (потенциально) любого языка. Задача сложная, но дающая ряд преимуществ. Создав однажды мета-средство мы резко упрощаем дальнейшую работу. Ну, и пишем мы это все на не C# и VB, а на Немереле и на самом Н2, что резко поднимает производительность. Хотя не скрою, объем работы огромный и нам будет не просто сделать все в срок. Но мы постараемся.

R>Но, ИМХО, все языки имеют пересечения только с академической точки зрения. Да, концепции типов, переменных, наследования и т.п. довольно похожи друг на друга. Но имплементация компиляторов абсолютно другая.

Мы не собираемся создавать универсальный движок для всех языков. Мы создаем язык для упрощения реализации других языков. Это не отменяет работу по каждому из языков. Это упрощает эту работу за счет понятия уровня разработки.

R>Например шарп вначале определяется с типами и их членами по всему проэкту, а уже затем парсит код внутри методов.

Это не верное утверждение. Парсинг тел методов, конечно же, проходит одновременно с парсингом типов. Вот типизация — другое дело.

R>В то время как Си++ парсает всё подряд: хочешь вызвать функцию имплементированую позже, будь добр, задекларируй её заранее.

С С++ все тоже самое. Единственное отличие — это необходимость использовать таблицу символов при парсинге. Это мы предоставим из коробки. Ну, а сама организация С++ позволяет создать эту таблицу символов во время парсинга, так как в С++ требуется предекларировать все типы перед использованием. Проблемы с парсингом С++ есть, но надеюсь, что мы их решим.

R>Хуже с темплейтами, где полностю отсутствует типизация.

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

R>А макросы Си/Си++, вообще, ломают все рамки со скобками.

Не знаю причем тут скобки, но таки да, препроцессор С++ — это серьезная проблема. Особенно include и define там очень мешают созданию полноценной поддержки IDE. Но у нас есть кое какие идеи. Так что может и тут удастся создать качественное решение. Хотя С++ для нас пока не приоритет.

R>Можно, конечно остановится, сказав: "это должно просто обрабатываться на уровне глупого препроцессора".

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

R>Но юзера тут же забухтят, — "А где мой интеллисенс? Да мне в Vim 15 лет назад лучше кодировалось!".

Препроцессор и даизайн С++, несомненно, препятствуют созданию качественного интелсенса. Но это общая проблема, а не только наша. Будем ее обходить.

R>Та же ситуация в JavaScript и SQL с их eval-фичами, или использованием их же как встроеных (embedded™) языков.

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

R>Там после включения какой-нибудь eval-напичканой библиотечки нужно подрубать искуственный интелект,

ИИ мы разрабатывать пока не будем

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

F> Кто знает, — для меня N пока решает очень узкий круг задач, там где я его имел мечты применить — увы не могу — мне нужен unsafe. А там где не хотел — и не надо.
unsafe и нам понадобился (парсер Н2 разгонять... на несколько десятков процентов). Влад его сейчас делает.

F> В любом случае ждём обещанных анонса/отчётов с полей боя о том что нас ждёт в будующем и какую роль в этом всём будет играть N2.
F> Без этого рассуждения на счет N1 — имхо — безсмысленны.
Тут нужно понять что Н2 это не язык общего назначения.
Это язык для создания языков.
Те у тебя будет полный контроль над парсером, типизацией и кодогенерацией.
Не нужен nemerle.dll? Не используй.
Не нужен .НЕТ? Хочешь натив или жабу? Не проблема.
Хочешь компиляцию под несколько платформ? Нивапросваще.

Короче на Н2 ты прикладной код писать не будешь. Ты будешь на нем делать язык для того чтобы решить свою задачу.
Ессно чтобы максимально облегчить это дело будет не только мощный ДСЛ для создания языков о и множество уже готовых языков, которые можно будет использовать.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, Аноним, Вы писали:

F>> CellRangeImpl имплементит и то и другое. Методам которые работают с CellRangeImpl — глубоко пофиг через какой интерфейс их позвали.
А>Речь не о нём, а о том что DocumentImpl теперь должен уметь возвращать как ICellRange так и ICellRange2 и все методы должны принимать как ICellRange, так и ICellRange2 и так для каждого изменившегося типа, для каждой новой версии.

То что вы хотите называется "Ковариантность"
и это свойство не зависит от статики-динамики типизации

Здравствуйте, Аноним, Вы писали:

А>Тем что в статике требуется полное описание интерфейса и полное описание интерфейса всех параметров всех методов. Если например меняется тип одного из параметров, меняется и интерфейс.

не всё ли равно где будет размещено "полное описание интерфейса всех параметров всех методов"
-в документации
или
-в коде в секции "интерфейс"

или вы хотите предложить революционный способ динамики без документации?

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

P>То что вы хотите называется "Ковариантность"
P>и это свойство не зависит от статики-динамики типизации
Нет, ковариантность я как раз не хотел сказать.

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

WH>unsafe и нам понадобился (парсер Н2 разгонять... на несколько десятков процентов). Влад его сейчас делает.

Очень приятная новость.

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

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

WH>>unsafe и нам понадобился (парсер Н2 разгонять... на несколько десятков процентов). Влад его сейчас делает.

DR>Очень приятная новость.

Автоматом в unsafe или просто поддержка данной секции в немерли?

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

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

F>> Кто знает, — для меня N пока решает очень узкий круг задач, там где я его имел мечты применить — увы не могу — мне нужен unsafe. А там где не хотел — и не надо.
WH>unsafe и нам понадобился (парсер Н2 разгонять... на несколько десятков процентов). Влад его сейчас делает.

Я так понимаю макросами не все тут решилось ?
Частично unsafe можно симулировать в частности макрос fixed.

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

_NN>Я так понимаю макросами не все тут решилось ?
_NN>Частично unsafe можно симулировать в частности макрос fixed.

Но это же просто пиннинг объектов, настоящих указателей поддерживаемых CLR ведь не появляется, а IntPtr годится разве что передать куда-нибудь.

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

_NN>Я так понимаю макросами не все тут решилось ?
_NN>Частично unsafe можно симулировать в частности макрос fixed.
Там только получение IntPtr
А этого не достаточно.
Нужны нормальные указатели. С арифметикой и типизацией.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

_NN>А вот F# тоже не тянет ненужное ?

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

F>> Если язык хочет быть под .NET — то он его должен утилизировать по полной. А именно, то, что я случайно увидел, навроде открытия нэйспэйсов по умолчанию и типа Some — это ересь, за которую рубить рубить рубить надо нафиг, с какого вообще что-то открывать по дефолту, а если я как раз нехочу этого?
_NN>Можно продумать как это отменить, а чем конкретно это вам мешает ?
Ну мешает тем, что схватить зависимость от Nemerle.dll — очень легко, и средств контроллить этого нет. В основном Nemerle.dll меня ничуть не парит, но есть некоторые минималистичные "проекты" которые не должны иметь внешних зависимостей кроме как от фреймворка.

_NN>А что там мешает сделать .Net 2.0 only ?
Опять же неясно как таргетить компилятор на него. Но это беда текущей реализации компилятора и только.

F>> Незачем на каждую лямбду вместо метода городить отдельный класс, с телом лямбды. Удобно для компиляции? Пусть так. Удобно для пользователей? Отнюдь — этот Function<XXXX> там вообще нафиг не впал, и я не думаю, что кто-нибуль адекватно сможет его объяснить.

using System;

class Program
{
    static Main() : void
    {
        Method(x => x + 1);
    }

    static Method(func : Func[int, int]) : void
    {
        Console.WriteLine( func(100) );
    }
}

Приводит к тому что в теле Program появляется новый класс, который реализует — Nemerle.Builtins.Function.
В шарпе же новый inner class НЕ генерируется. Генерируется метод с телом лямбды и поле кешированным делегатом.
Т.е. что не нравится:
1. в таком простом случае имеем зависимость от Nemerle.dll.
2. генерировать класс на каждый чих, может быть удобно, но довольно расточительно. Рантайму от этого точно никак не легче.

Каковы плюсы использования Nemerle.Builtins.Function?
1. Ну по всей видимости это позволяет возложить на рантайм кеширование делегата, упрощая код самого компилятора.
2. По идее обращение к такому делегату заставляет CLR проинициализировать класс делегата и уже не нужны проверки на существование делегата (т.е. возможно даже есть выигрыш в рантайме, т.к. код генерируемый шарпом вынужден постоянно проверять закеширован ли делегат). Но не помню уже точно как там происходит, CLR по моему утыкает код с проверками проинициализирован ли класс, и в итоге вполне можем получить тоже самое.

С другой стороны, Nemerle конечно же традиционно генерирует какую-то ерунду, сводя на нет плюсы которые мы только что раскрыли:

    IL_0000: ldsfld class Program/_N__N_lambda__3301__3377 Program/_N__N_lambda__3301__3377::Instance
    IL_0005: stloc.0
    IL_0006: ldloc.0
    IL_0007: dup
    IL_0008: ldvirtftn instance !1 class [Nemerle]Nemerle.Builtins.Function`2<int32, int32>::apply(!0)
    IL_000e: newobj instance void class [mscorlib]System.Func`2<int32, int32>::.ctor(object, native int)
    IL_0013: call void Program::Method(class [mscorlib]System.Func`2<int32, int32>)
    IL_0018: ret

В строчке IL_000e — мы создаём делегат, и никакого кеша для System.Func оказывается не существует.

Конечно же переписав код без Func, а используя функциональный тип — имеем уже код не имеющий этой проблемы:

.method private hidebysig static 
    void Main () cil managed 
{
    // Method begins at RVA 0x2064
    // Code size 13 (0xd)
    .maxstack 1
    .entrypoint
    .locals init (
        [0] class [Nemerle]Nemerle.Builtins.Function`2<int32, int32>
    )

    IL_0000: ldsfld class Program/_N__N_lambda__3327__3341 Program/_N__N_lambda__3327__3341::Instance
    IL_0005: stloc.0
    IL_0006: ldloc.0
    IL_0007: call void Program::Method(class [Nemerle]Nemerle.Builtins.Function`2<int32, int32>)
    IL_000c: ret
} // end of method Program::Main

Я понимаю, что собственный функциональный тип — это здорово. Но пока что есть поддержка исключительно .NET — и игнорировать стандартные типы делегатов... некошерно. Более того в идеале, он просто должен кешировать целевой тип делегата, а не свой.

Зато теперь глаз режет использование слота (т.е. лишние stloc/ldloc и locals) — все уверены, что JIT это вообще будет оптимизировать, а не тупо выделит место на стеке положит туда и прочитает? Хотя к изначальному вопросу это конечно отношения не имеет, но в целом хотелось бы конечно получать код более качественный. Хотелось бы что бы в будущем этому тоже уделялось внимание.

F>> Стоит вспомнить мой тест, как только я переписал на X -> Y, вместо Func[X,Y] — скорость компиляции его упала раза в 3.

_NN>Это стоит записать в разряд недоработок, и исправить

_NN>C# компилятор тоже создает класс для лямбды.

На замыкания. При том потом туда хренячит и методы лямбд, если в этом он увидел смысл.

F>> В общем — N — хороший язык, действительно решает кучу задач. Но и детских болезней у него капец как много. От глупого IL кода, с теми же def — каждый следующий def что-то не собирается переиспользовать слот вообще — так и в целом встречались.

_NN>Делов то, подправьте реализацию и будет вам счастье

Не уверен что это так просто.

F>> Стандартная библиотека должна быть подключена только тогда когда это попросит пользователь. Никакого неявного using System C# не делает. А немерле делает. Ф ТОПКУ!!!
_NN>Код компилятора открыт для улучшений.
F>> [Record] — нафиг. Это дрэг. А особенно с variant-ом.
_NN>Не нравится Record , не пользуйтесь. Никто вас не обязывает.

using System;

[Record]
class X
{
   x : int;
}

Отлично, код компилируется, хотя я об этом его не просил.
Я за существование полезных макросов, но по дефолту открывать нэймспейсы с ними, как по мне, стоит только для фундаментальные макросов, навроде if. А так у меня есть Record, но "запретить" его использовать я никак не могу. Есть какой-то ключик о котором я не знаю?

_NN>Давайте вы будете писать конкретные проблемы.
_NN>Чем не нравится option ?
_NN>Между прочим в том же F# открыто пространство имен с option, Some, None. Но это вас не смущает.
Аналогично как с делегатами. Получаю в нагрузку некотроллируемую зависимость. Это следствие вышеописанного.

_NN>В каком виде нужен unsafe ?
_NN>На текущий момент несколько вариантов.
_NN>1. Использовать C#.
_NN>2. Использовать Masrhal и обернуть в макрос для удобства.
_NN>3. Использовать C++/CLI .
Поддержка указателей. Использую C#, т.к. других вариантов нет. unsafe — это не только интероп, но крайне полезен при реализации методов критичных по скорости.

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

Да знаю я.

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

P>>То что вы хотите называется "Ковариантность"
F> Нет, ковариантность я как раз не хотел сказать.

я отвечал для товарища анонима

DocumentImpl теперь должен уметь возвращать как ICellRange так и ICellRange2 и все методы должны принимать как ICellRange, так и ICellRange2 и так для каждого изменившегося типа, для каждой новой версии.

interface ICellRange ...
interface ICellRange2 : ICellRange ...

interface IDocument
{
  ICellRange GetCell();
}
interface IDocument2 : IDocument
{
  ICellRange2 GetCell();
}

class CellRangeImp : ICellRange2 ...

class DocumentImp : IDocument2
{
  public CellRangeImp GetCell()
  {
    return new CellRangeImp();
  }
}

c#3.5
и ни строчки лишнего, ни строчки динамики

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

А.

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

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

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

_NN>>А вот F# тоже не тянет ненужное ?

F> Не имею ни малейшего понятия. F# я несколько раз загружал, потому что в какой-то тулзе нужно было поправить баг, но был настолько впечатлён — что стараюсь держаться от него подальше.

Дам подсказку, в F# присутствуют все вами перечисленные проблемы с открытыми пространствами имен и зависимостями =)

F> Ну мешает тем, что схватить зависимость от Nemerle.dll — очень легко, и средств контроллить этого нет. В основном Nemerle.dll меня ничуть не парит, но есть некоторые минималистичные "проекты" которые не должны иметь внешних зависимостей кроме как от фреймворка.
Как раз большинству это не мешает.
Это сродни С++ проектам без CRT.
Не спорю, могло быть и полезно, но никто это не реализовывал, потому как не типичный случай.

_NN>>А что там мешает сделать .Net 2.0 only ?
F> Опять же неясно как таргетить компилятор на него. Но это беда текущей реализации компилятора и только.
F>Приводит к тому что в теле Program появляется новый класс, который реализует — Nemerle.Builtins.Function.
F>В шарпе же новый inner class НЕ генерируется. Генерируется метод с телом лямбды и поле кешированным делегатом.
Оптимизацию приделать можно было бы
F>Т.е. что не нравится:
F>1. в таком простом случае имеем зависимость от Nemerle.dll.
F>2. генерировать класс на каждый чих, может быть удобно, но довольно расточительно. Рантайму от этого точно никак не легче.
Это в следствии от того, что функциональный тип появился в Nemerle когда еще не было C# 3 и не было System.Func / System.Action.
А переделывать все это не было времени.
Как уже я говорил, можно вынести на обсуждение и подумать как это улучшить.

F>Зато теперь глаз режет использование слота (т.е. лишние stloc/ldloc и locals) — все уверены, что JIT это вообще будет оптимизировать, а не тупо выделит место на стеке положит туда и прочитает? Хотя к изначальному вопросу это конечно отношения не имеет, но в целом хотелось бы конечно получать код более качественный. Хотелось бы что бы в будущем этому тоже уделялось внимание.
Кодогенерацию можно улучшать и улучшать, но на это точно времени ни у кого нет.

F> Не уверен что это так просто.

Смотря что конечно.

F>Отлично, код компилируется, хотя я об этом его не просил.
F>Я за существование полезных макросов, но по дефолту открывать нэймспейсы с ними, как по мне, стоит только для фундаментальные макросов, навроде if. А так у меня есть Record, но "запретить" его использовать я никак не могу. Есть какой-то ключик о котором я не знаю?
Предложение дельное, выносите на обсуждение.

F> Поддержка указателей. Использую C#, т.к. других вариантов нет. unsafe — это не только интероп, но крайне полезен при реализации методов критичных по скорости.
Как тут писали будущее не за горами

F> Да знаю я.

Ну так за чем дело встало ?

P.S.
Давайте выделим конкретные проблемы в отдельные темы так чтобы их можно было обсудить.
Также предлагаю вам описать возможные решения.

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

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

И ещё наверное удобнее на ты...

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

WH>>unsafe и нам понадобился (парсер Н2 разгонять... на несколько десятков процентов). Влад его сейчас делает.

DR>Очень приятная новость.

Ну, я делаю не совсем ансфэйф. Только его часть позволяющую зпинить массив или строку и получить доступ к нему по индексу (без проверок).

Здравствуйте, Аноним, Вы писали:

А>Автоматом в unsafe или просто поддержка данной секции в немерли?

Что?

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

VD>Ну, я делаю не совсем асфэйф. Только его часть позволяющую зпинить массив или строку и получить доступ к нему по индексу (без проверок).

Мне больше ничего и не надо.

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

WH>Нужны нормальные указатели. С арифметикой и типизацией.

Думаю, за завтра я это дело доделаю.

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

F>> Стоит вспомнить мой тест, как только я переписал на X -> Y, вместо Func[X,Y] — скорость компиляции его упала раза в 3.

_NN>Это стоит записать в разряд недоработок, и исправить

_NN>C# компилятор тоже создает класс для лямбды.

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

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

_NN>>Это стоит записать в разряд недоработок, и исправить

_NN>>C# компилятор тоже создает класс для лямбды.

VD>Это надо, скорее, записать в разряд легкомысленных высказываний со стороны fddima. Скорее всего он что-то напутал или намеренно искажает факты. Не с чего там компиляции замедляться. А вот исполнение от функциональных типов только ускоряется.
Ну ладно, и вправду сбрехал. Почему-то показалось что сильно изменилось время.
На самом деле:

Func[X,Y] — 640ms
X -> Y — 748ms

Но из всего, на что можно было бы ответить, ты почему-то выбрал самое неважное.

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

F>Но из всего, на что можно было бы ответить, ты почему-то выбрал самое неважное.

Там по каждому пункту домыслы. Ввязываться в споры у меня просто нет желания. Да и грешно спорить с ИМХОм человека. Обоснуй свои высказывания, тогда можно говорить о чем-то конкретно.

Все что я смог вынести из твоего пространного сообщения — тебе не нравится наличие дополнительной ДЛЛ. Чем она помешала так и осталось за кадром.

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

F> В основном Nemerle.dll меня ничуть не парит, но есть некоторые минималистичные "проекты" которые не должны иметь внешних зависимостей кроме как от фреймворка.

Так компилируй такие проекты без стандартной библиотеки, а с необходимыми исходниками из нее. Они доступны каждому. Думаю, подключить файл к проекту тебе не составит труда.

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

F>> В основном Nemerle.dll меня ничуть не парит, но есть некоторые минималистичные "проекты" которые не должны иметь внешних зависимостей кроме как от фреймворка.
VD>Так компилируй такие проекты без стандартной библиотеки, а с необходимыми исходниками из нее. Они доступны каждому. Думаю, подключить файл к проекту тебе не составит труда.
Тогда после этого я немогу подключить такую сборку к другому проекту на Nemerle — он начинает сыпать кучу ворнингов и вместо того что бы референсить Nemerle.dll — референсит мою сборку (первую референсит). Т.е. это тоже получается не очень решением.
Хотя возможно если подправить компилятор, то вполне реально его заставить искать все эти типы в другом нэймспейсе.

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

F> Тогда после этого я немогу подключить такую сборку к другому проекту на Nemerle — он начинает сыпать кучу ворнингов и вместо того что бы референсить Nemerle.dll — референсит мою сборку (первую референсит). Т.е. это тоже получается не очень решением.

Ты уж как-нибудь определись. Или тебе нудно делать минимальные проекты без зависиостей, или ты хочешь сборки плодить. Если немеровых сборок в проекте больше одной, то имеет смысл использовать Nemerle.dll и не заниматься ерундой. Одна мелка сборка ни на что не влияет.

F> Хотя возможно если подправить компилятор, то вполне реально его заставить искать все эти типы в другом нэймспейсе.

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

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

F> Я то определился. Задача сделать сборку без зависимостей, ничего кроме mscorlib/System ей не нужно. Это требование, можешь с ним не соглашаться, но оно от этого никуда не денется.

Брось ты изучение немерла. Оно тебе явно не надо. У тебя задачи совершенно иные. Немерл он для тех кому нужны вариантные типы, кортежи, неизменяемые структуры данных вроде списков и словарей, макросы и т.п. Тем кому не нужно зависимостей от всего этого нужно использовать шарп. А еще лучше ассемблер. Там вообще полный контроль будет. Зачем над собой издеваться то?

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

<skip/>

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

Pull-request в github-е или патч в форум и можно будет протолкнуть в компилятор.

Дело за малым

P.S.
Если только жаловаться без предложений, то смысла действительно в этом нет.
В том же C# есть недоработки, но на них ты не жалуешься, а все потому что никто их не починит!
А вот в Nemerle можно и пожаловаться и самим же исправить.

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

VD>Брось ты изучение немерла. Оно тебе явно не надо. У тебя задачи совершенно иные. Немерл он для тех кому нужны вариантные типы, кортежи, неизменяемые структуры данных вроде списков и словарей, макросы и т.п. Тем кому не нужно зависимостей от всего этого нужно использовать шарп. А еще лучше ассемблер. Там вообще полный контроль будет. Зачем над собой издеваться то?
Зачем всё так утрировать и обобщать? Ну есть единичная потребность и всё. На шарпе и писано, но изначально хотел на N.
Да и сейчас хочется иметь минималистичный язык, в большей степени с макросами, нежели с встроенным list и option. Короче без stdlib. Это вполне возможно.
Ну и сказал бы что текущий компилятор под это не заточен, и заточен не будет, а ключик nostdlib годится только для сборки stdlib.

Ну и нет так нет.

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

F> Ну и сказал бы что текущий компилятор под это не заточен, и заточен не будет, а ключик nostdlib годится только для сборки stdlib.

Ну и нет так нет.

На это не заточен ни один в мире компилятор. Просто у МС есть возможность сложить се необходимое во фрэймворк.

Немерл не мыслим без таких вещей как list[T], option[T], кортежей и т.п. Если ты все это не используешь, то ты пишешь на C#. Ну, и пиши на нем. У МС очень быстрый компилятор и качественная IDE + ReSharper.

Так что идея отказаться от Nemerle.dll совершенно не реалистична. К тому же в этом нет никакого смысла.

Я, кстати, так и не услышал зачем нужно отказываться от Nemerle.dll.

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

F>

F>.method private hidebysig static 
F>    void Main () cil managed 
F>{
F>    // Method begins at RVA 0x2064
F>    // Code size 13 (0xd)
F>    .maxstack 1
F>    .entrypoint
F>    .locals init (
F>        [0] class [Nemerle]Nemerle.Builtins.Function`2<int32, int32>
F>    )

F>    IL_0000: ldsfld class Program/_N__N_lambda__3327__3341 Program/_N__N_lambda__3327__3341::Instance
F>    IL_0005: stloc.0
F>    IL_0006: ldloc.0
F>    IL_0007: call void Program::Method(class [Nemerle]Nemerle.Builtins.Function`2<int32, int32>)
F>    IL_000c: ret
F>} // end of method Program::Main
F>

F>Зато теперь глаз режет использование слота (т.е. лишние stloc/ldloc и locals) — все уверены, что JIT это вообще будет оптимизировать, а не тупо выделит место на стеке положит туда и прочитает? Хотя к изначальному вопросу это конечно отношения не имеет, но в целом хотелось бы конечно получать код более качественный. Хотелось бы что бы в будущем этому тоже уделялось внимание.

Я, кстати, знаю причину по которой stloc/ldloc-и появляются в генерируемом коде. Кто-то не очень чисто написал патч для поддержки try/catch/finally в выражениях. Я пробовал его поправить, но какие-то тесты отказались проходить. Могу ткнуть в конкретное место компилятора, требующее "отладки методом пристального взгляда".

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

F>> Ну и сказал бы что текущий компилятор под это не заточен, и заточен не будет, а ключик nostdlib годится только для сборки stdlib.

Ну и нет так нет.
VD>На это не заточен ни один в мире компилятор. Просто у МС есть возможность сложить се необходимое во фрэймворк.
Ну почему же сразу нет таких — есть, вспомни C и C++.
Сейчас в N ключ nostdlib лишь заставляет поискать типы в другом месте, при этом список этот весьма увесистый, и в не зависимости будет ли использован в итоге, например, list — компилятор сразу же требует его наличие. Поэтому это скорее god-mode ключ --compile-stdlib. Да, можно с помощью него всунуть библиотеку к себе в проект, но ещё проще ничего не выдумывать и воспользоваться ilmerge. Как я уже говорил, это не плохо и не хорошо — просто я ожидал немного другого.
По поводу сложить всё необходимое во фреймворк — то так никто ж и не мешает использовать то, что там лежит. Но там почти ничего нужного не лежит.

VD>Немерл не мыслим без таких вещей как list[T], option[T], кортежей и т.п. Если ты все это не используешь, то ты пишешь на C#. Ну, и пиши на нем. У МС очень быстрый компилятор и качественная IDE + ReSharper.
VD>Так что идея отказаться от Nemerle.dll совершенно не реалистична. К тому же в этом нет никакого смысла.
Тотально избавляться от Nemerle.dll я и не предлагал, — будет только хуже. Там где нахожу удобным list я использую, и АТД тоже, — они и так всегда были, только солнце закатывалось вручную. Кортежи я тоже нахожу вполне удобными.

Но N и сейчас может генерировать сборки без зависмости на Nemerle.dll. Т.е. потенциально ему ничего это не мешает делать, в ущерб возможностям конечно же. Собственно всего что мне не хватало пожалуй это ключика-гварда который бы фэйлил компиляцию, если результат начинает референсить Nemerle.dll и хочется простенькие лямбды не завязанные на функциональный тип, во вполне определённых случаях. Да, при этом код от шарпа далеко не уйдёт, но будет синтаксис N, а самому N точно от этого не станет хуже. С лямбдами не завязанными на функциональный тип я как бы и не предлагал избавлятся от Function насовсем, а наоборот при этом в итоге явно улучшить генерируемый код.

VD>Я, кстати, так и не услышал зачем нужно отказываться от Nemerle.dll.
Небольшая сборка общего назначения, которая сама по себе в 10 раз меньше Nemerle.dll. Никаких особых возможностей N она не может утилизировать, просто потому что негде там использовать АТД, list, option и даже макросы не нужны. А когда это так — и зависимость она не должна иметь.

Да шарп, в этом случае отлично подходит, — но с таким подходом действительно можно писать хоть на ilasm. Писать то ведь можно на чём угодно. Пусть не очень common case — но и не что-то совсем уж космическое. За сим предлагаю закончить эту дискуссию. Для этого случая буду продолжать просто юзать шарп, и ни кому не буду сверлить мозг.

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

H>Я, кстати, знаю причину по которой stloc/ldloc-и появляются в генерируемом коде. Кто-то не очень чисто написал патч для поддержки try/catch/finally в выражениях. Я пробовал его поправить, но какие-то тесты отказались проходить. Могу ткнуть в конкретное место компилятора, требующее "отладки методом пристального взгляда".
Ткни.

Хотя именно в этом месте помоему происходит от того, что код на самом деле был типа такого: { def _lambda = ...; method(_lambda); } — и на вот этот def всегда генерируется слот в locals, ну а затем его инициализируем (stloc), а ldloc соответственно это уже использование этой переменной.

Я так подозреваю, что это необходимо делать в Debug, но в релизе/с оптимизацией это вроде как явно лишнее.

С другой стороны ещё нужно точно как-то посмотреть, чего там JIT генерит на самом деле с оптимизацией (что-то забыл как), может он такое и "хавает", оптимизация вроде как довольно простая, и её вполне можно делать именно на уровне IL. А случай довольно распространён.

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

_NN>Если только жаловаться без предложений, то смысла действительно в этом нет.

Понимаешь, тут нет решений без недостатков. Влад может сколько угодно говорить, что никого не парит зависимость от Nemerle.dll, но меня парит. Просто потому, что эта зависимость на сугубо конкретную версию Nemerle.dll. Мне надо следить, чтобы у всей команды была одна версия компилятора и обновлялась она одновременно. Если Nemerle основной язык проекта это еще допустимо, но когда столько возни из-за либы — люди перестают меня понимать.

Я бы не жаловался, но Влад-то твердит, что все нормально и никого это не парит.

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

Z>Понимаешь, тут нет решений без недостатков. Влад может сколько угодно говорить, что никого не парит зависимость от Nemerle.dll, но меня парит. Просто потому, что эта зависимость на сугубо конкретную версию Nemerle.dll.
А что в своей сборке нельзя сделать ссылку не на конкретную версию?

Z>Мне надо следить, чтобы у всей команды была одна версия компилятора и обновлялась она одновременно. Если Nemerle основной язык проекта это еще допустимо, но когда столько возни из-за либы — люди перестают меня понимать.
Мы тут занимаемся хардкорным макросостроением с бутстрапингом.
И проблем с разными версиями немерла у разных разработчиков не имеем.
Что мы делаем не так?

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

Z>>Я бы не жаловался, но Влад-то твердит, что все нормально и никого это не парит.
WH>Я так и не понял что у тебя за проблема.

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

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

Z>У вас весь проект в исходниках, нет зависимостей от бинарников собранных немерлом. Соответственно таких конфликтов быть не может.
А вот эта папка мне приснилась?
https://github.com/rampelstinskin/ParserGenerator/tree/master/N2/Boot/Net-4.0

Z>Влад пытается доказать, что я один такой (да и ты сейчас намекаешь), но вряд-ли кто-то будет утверждать, что невозможность сделать nuget package является мелкой проблемой. Ирония в том, что доработки nuget для поддержки немерловых проектов дают возможность подключать только либы написанные на других языках.
А в чем проблема с нугетом то?
Или там нет других либ которые обновляются?

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

Z>>У вас весь проект в исходниках, нет зависимостей от бинарников собранных немерлом. Соответственно таких конфликтов быть не может.
WH>А вот эта папка мне приснилась?
WH>https://github.com/rampelstinskin/ParserGenerator/tree/master/N2/Boot/Net-4.0

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

У меня честный бут, он не только билдит, но и Nemerle.dll используется от него же (должно все билдиться без установки немерла). Интеграцию начинает плющить сразу как только встает версия немерла отличная от бута.

Z>>Влад пытается доказать, что я один такой (да и ты сейчас намекаешь), но вряд-ли кто-то будет утверждать, что невозможность сделать nuget package является мелкой проблемой. Ирония в том, что доработки nuget для поддержки немерловых проектов дают возможность подключать только либы написанные на других языках.
WH>А в чем проблема с нугетом то?
WH>Или там нет других либ которые обновляются?

Если я создаю бинарную либу на nemerle — я прошиваю в ней ссылку на конкретную версию nemerle.dll. Засовывать ее в nuget смысла мало. Она будет работать только у тех, у кого стоит та же самая версия немерла.

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

Z>На всякий случай проверил еще раз, зависимостей от файлов в этой папке в проекте не нашел. Это только тулза для билда, все зависимости идут на текущий установленный немерл. Пример некорректный.
Это у тебя проект некорректный.
Причем лично мне не ясно, зачем тебе вообще бут?

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

Z>У меня честный бут, он не только билдит, но и Nemerle.dll используется от него же (должно все билдиться без установки немерла).

Остается понят зачем это нужно.

"Установка" — это очень растяжимый символ. Сложить бинарники в каталог — это вполне себе установка.

Z>Интеграцию начинает плющить сразу как только встает версия немерла отличная от бута.

Так компиляйся с текущей версий и проблем не будет.

Z>>>Влад пытается доказать, что я один такой (да и ты сейчас намекаешь), но вряд-ли кто-то будет утверждать, что невозможность сделать nuget package является мелкой проблемой. Ирония в том, что доработки nuget для поддержки немерловых проектов дают возможность подключать только либы написанные на других языках.
WH>>А в чем проблема с нугетом то?
WH>>Или там нет других либ которые обновляются?

Z>Если я создаю бинарную либу на nemerle — я прошиваю в ней ссылку на конкретную версию nemerle.dll. Засовывать ее в nuget смысла мало. Она будет работать только у тех, у кого стоит та же самая версия немерла.

Это проблема самого дотнета. Любая общая сборка приведет к тому же результату.

То что ты предлагаешь с огромной вероятностью приведет к ДЛЛ-хелу и невозможности понять, что же в реальности произошло.

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

Возможно я не прав и ты получишь внятную диагностику. Хотя верится в это с трудом.

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

Z>На всякий случай проверил еще раз, зависимостей от файлов в этой папке в проекте не нашел. Это только тулза для билда, все зависимости идут на текущий установленный немерл. Пример некорректный.

Вообще-то "тулза" (а в реальности компилятор) собирается с помощью самой себя (бутстрапится). И это самый правильный подход.

Я уже не помню твоих проблем, напомни их еще раз.

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

Z>>На всякий случай проверил еще раз, зависимостей от файлов в этой папке в проекте не нашел. Это только тулза для билда, все зависимости идут на текущий установленный немерл. Пример некорректный.
WH>Это у тебя проект некорректный.

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

Еще раз — у тебя все работает пока не появились бинарные зависимости от dll собраных немерлом. Например что-то захотелось выделить в nuget package.

WH>Причем лично мне не ясно, зачем тебе вообще бут?

Бут нужен, чтобы это все билдилось даже если нет под рукой человека, который способен найти и установить нужную версию немерла для билда. Авралы "я установил немерл, а у меня ничего не билдится" мне из отпуска не нужны. Переставлять немерл на билдсервере тоже не нужно.

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

Z>Я не пойму, ты правда не понимаешь или делаешь вид? Ты утверждал, что у тебя есть зависимости от бинарников и показывал на бустрап. От его библиотек нет зависимостей в проекте, потому и пример "у меня все работает" некорректен. Вместо аргументов ты начинаешь делать необоснованные утверждения про проект который в глаза не видел.
Так я тебе показал, как надо делать бутстрап.

Z>Еще раз — у тебя все работает пока не появились бинарные зависимости от dll собраных немерлом. Например что-то захотелось выделить в nuget package.
Ох.
А что происходит, если обновляется любая другая бинарная библиотека?

Z>Бут нужен, чтобы это все билдилось даже если нет под рукой человека, который способен найти и установить нужную версию немерла для билда. Авралы "я установил немерл, а у меня ничего не билдится" мне из отпуска не нужны. Переставлять немерл на билдсервере тоже не нужно.
А вы что больше никакую другую внешнюю библиотеку не используете?
Если используете, то как решаете проблему обновления?

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

VD>Так компиляйся с текущей версий и проблем не будет.

Опять двадцать пять. У меня есть скомпилированная dll. Я не хочу ее подключать исходниками.

Z>>Если я создаю бинарную либу на nemerle — я прошиваю в ней ссылку на конкретную версию nemerle.dll. Засовывать ее в nuget смысла мало. Она будет работать только у тех, у кого стоит та же самая версия немерла.

VD>Это проблема самого дотнета. Любая общая сборка приведет к тому же результату.

В .net работают nuget packages. Для немерловых либ — нет.

VD>То что ты предлагаешь с огромной вероятностью приведет к ДЛЛ-хелу и невозможности понять, что же в реальности произошло.
VD>Ты бы хоть попробовал к чему приведет твое предложение. Создай две версии библиотек с одинаковым номером версии, но разной сигнатурой и попробуй подменить их без перекомпиляции ссылающейся сборки.

Значит нужна стабильная ветка в которой правят баги, но не трогают сигнатуры. И master, в котором делают новые фичи и мерджат в него stable.

VD>Возможно я не прав и ты получишь внятную диагностику. Хотя верится в это с трудом.

ЕМНИП диагностика будет достаточно внятной, но такого счастья и правда не нужно.

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

_NN>Как я понял имеем зависимость:
_NN>Y.dll <- X.dll <- Nemerle.dll

_NN>При чем X.dll распространяется исключительно в бинарном виде, т.е. ему нужна определенная версия Nemerle.dll.
_NN>А значит даже указав SpecificVersion False для X.dll, мы все равно прибиваемся к конкретной версии Nemerle.dll, потому как повлиять на ссылки X.dll уже не можем.

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

ncc_building_MyMacros.dll <- MyMacros.dll(boot) <- Nemerle.dll v.X
                 ^------------------------------------|

при обновлении ncc получается

ncc_building_MyMacros.dll <- MyMacros.dll(boot) <- Nemerle.dll v.X
                 ^------------------------------<- Nemerle.dll v.X+1

у меня так и не получилось нормально это настроить- чтоб билдилось без проблем

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

Z>Значит нужна стабильная ветка в которой правят баги, но не трогают сигнатуры. И master, в котором делают новые фичи и мерджат в него stable.

Что значит "стабильная ветка в которой ... не трогают сигнатуры"?

Почему под такую не проходят релизы? Вот на сегодня есть 1.0 и 1.1. Юзай их. Все что берется из мастера априори не стабильно.

Гарантировать, что не будет изменений невозможно. Если сама Nemerle.dll относительно стабильна, то другие либы — нет. А с ними будет такая же проблема когда кто-то захочет из из нюгета использовать.

VD>>Возможно я не прав и ты получишь внятную диагностику. Хотя верится в это с трудом.

Z>ЕМНИП диагностика будет достаточно внятной, но такого счастья и правда не нужно.

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

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

Да, развивая тему — при этом, вероятно возможно будет создать нюгет пэкеджи Nemerle Runtime 1.0/1.1/1.2 — на которые смогут ссылаться другие Nemerle-библиотеки. При этом обновления Nemerle Runtime 1.0/1.1/1.2 — будут мэйнтэйниться Nemerle Team, — а библиотеки их авторами. Но без обратной совместимости тут никуда. Ну это на правах дурной идеи, как я уже говорил, с нюгетом плотно не знакомился.

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

Z>>Я не пойму, ты правда не понимаешь или делаешь вид? Ты утверждал, что у тебя есть зависимости от бинарников и показывал на бустрап. От его библиотек нет зависимостей в проекте, потому и пример "у меня все работает" некорректен. Вместо аргументов ты начинаешь делать необоснованные утверждения про проект который в глаза не видел.
WH>Так я тебе показал, как надо делать бутстрап.

Так я умею делать бустрап. Проблема не в бутстрапе, а в зависимости от nemerle.dll через другую либу.

Z>>Еще раз — у тебя все работает пока не появились бинарные зависимости от dll собраных немерлом. Например что-то захотелось выделить в nuget package.
WH>Ох.
WH>А что происходит, если обновляется любая другая бинарная библиотека?

Любая другая библиотека общего назначения, например log4net, старается держаться одной версии как можно дольше. И уж точно не меняет версию на багфикс релизах. Зависимость от нее не очень опасна.

В принципе, это проблема платформы вообще. Поддержка библиотеки имеющей в зависимости от себя другую, часто меняющуюся библиотеку, приносит немалый геморой. В Java проблема давно обсосана, созданы всякие maven'ы для автоматизации этого бардака.

Z>>Бут нужен, чтобы это все билдилось даже если нет под рукой человека, который способен найти и установить нужную версию немерла для билда. Авралы "я установил немерл, а у меня ничего не билдится" мне из отпуска не нужны. Переставлять немерл на билдсервере тоже не нужно.
WH>А вы что больше никакую другую внешнюю библиотеку не используете?
WH>Если используете, то как решаете проблему обновления?

Какую проблему обновления?

	От:	hi_octane
	Дата:	11.08.12 15:08
	Оценка:	1 (1) +1

	От:	fddima
	Дата:	15.08.12 00:37
	Оценка:	+3 -1

	От:	fddima
	Дата:	17.08.12 20:28
	Оценка:	17 (2) +1

	От:	Аноним
	Дата:	14.08.12 12:24
	Оценка:

	От:	Ziaw
	Дата:	18.08.12 03:00
	Оценка:	15 (2)

	От:	WolfHound
	Дата:	14.08.12 17:03
	Оценка:	1 (1) +1

От:	Don Reba	https://stackoverflow.com/users/49329/don-reba
Дата:	13.08.12 20:28
Оценка:	+1

От:	VladD2	www.nemerle.org
Дата:	14.08.12 22:32
Оценка:	+1

От:	_NN_	www.nemerleweb.com
Дата:	15.08.12 10:18
Оценка:	+1

От:	hardcase	http://nemerle.org
Дата:	16.08.12 09:36
Оценка: