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

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

C>>А что тут, собственно, делается?
WH>Парсится и типизируется выражение if.

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

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

WH>Примеры пойдут ответами на это сообщение.

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

Потому что я не уверен, что хотя бы читателей форума вообще понимает о чем речь.

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

VD>Да? Ну, тогда тебе не составит труда конструктивно раскритиковать мое решение.
Ты про ту гору нерасширяемого императива, который наворачивается на императивный типизатор в котором никто ничего не понимает?


VD>Лож. Я привел вполне понятный код который решает задачу и не создает дополнительных проблем, как твой.
Мой код проблем не создает.

VD>Не, не. Меня не интересует перечисление. Меня интересует псевдокод реализации с комментариями. Реализацию foreach я тебе уже приводил. В прочем, вот она еще раз:
1)Твой код не расширяем.
Попробуй добавить IterateByMyCollectionImpl без изменения макроса foreach.
2)Твой код требует чтобы тип коллекции был извествен до того как начнет работать макра.
А что делать, если тип выводиться на основе тела цикла?

VD>То же как типизировать этот код ровным счетом никак не повлияет на наличие в нем "кучу возни на ровном месте".
Повлияет. Никакой возни не будет.
Совсем не будет.

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

VD>Если мы хотим получить качественное решение, то надо их искать (предлагать), а не аппелировать черт знает к чему.
Вот и перестань апеллировать черт знает к чему, а попробуй разобраться в том что я говорю.

VD>Вот ты затронул тему протаскивания локешонов и местоположения комплита. Так покажи как твое решение будет их решать. Это будет конструктивно.
Т.к. у меня нет трансформаций АСТ во время работы ИДЕ и вся типизация описана декларативно у меня такой проблемы просто не возникнет.
Кодогенератор просто сгенерирует весь нужный код.

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

WH>3)Собственно язык описания правил вывода типов.
WH>Мои мысли в данный момент крутяться вокруг Mercury.
WH>Несколько упрощенный Mercury будет отличной основой для создания языка описания типизации.
WH>Я выбрал Mercury ибо типизация это поиск с откатами. Как раз то вокруг чего построен этот язык.

+1

WH>Пролог пошёл лесом, ибо Mercury это пролог сделанный правильно.

в чем именно, в контексте вывода типов, Меркюри лучше Пролога?

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

C>Предлагаю или конкретно описать задачу, ее решение и конкретно что делается в коде, и какие проблемы у if из N1, или спорить с Владом в скайпе.
Когда Влад через пару лет мне заявит что это он придумал типизаровать АСТ я его в эту тему буду тыкать.

C>Потому что я не уверен, что хотя бы читателей форума вообще понимает о чем речь.
Не стоит говорить за всех.

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

C>в чем именно, в контексте вывода типов, Меркюри лучше Пролога?
Скорость работы, статическая типизация и отсутствие императива.
Короче в прологе нет ничего, что было бы лучше, чем в меркури.

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

WH>>pred ConvertibleTo(from : Type, itemType : Type)
WH>>mode (in, in) is semidet //Проверяет что один тип приводим к другому.
WH>>mode (in, out) is multi //При помощи бектрекинга перебирает все типы к которым можно привести данный.

VD>Вот это вот вообще не понятно. "semidet" так просто какое-то шифрование. Что это значит то?

Выходит что-то типа nullable, или bool

either have no solutions or have one solution, then that mode is semideterministic(semidet);

Похоже 2 перегрузки, первая принимает 2 параметра и возвращает true/false,
вторая принимает 1 параметр и возвращает список.

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

C>А почему все так сложно по сравнению с Н1?
1)Не так уж и сложно.
2)Можно насыпать сахару.
3)На макрах побольше Н1 сольет даже без сахара.

C>Не то что бы я критично настроен, но зачем вообще отдельная типизация для всех конструкций, кроме встроенных в язык?
Например PegGrammar без этого просто невозможно реализовать.
Сейчас это делается руками в макросе жутким кодом.

Макросам типа foreach необходима информация о типах для того чтобы сгенерировать код.

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

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

S_S>Выходит что-то типа nullable, или bool
S_S>

S_S>either have no solutions or have one solution, then that mode is semideterministic(semidet);

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

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

C>В мире пролога/меркюри это означает, что после нахождения первого решения, остальные искаться уже не будут.
Нет. В мире меркури это означает, что есть ровно 0 или 1 решение.
Остальные решения искаться не будут по тому что их нет.
Совсем нет.
Гарантированно компилятором.

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

WH>Какую регрессию?

Куча невнятного кода которого раньше не было нужды писать — это регрессия.

WH>Все что добавилось по сравнению с твоим подходом это нормальные сообщения об ошибках.

А это откровенная неправда. Я тебе показал решение которое обеспечивает качественное сообщение об ошибке.

WH>В прочем если хочешь получать мутные сообщения в стиле Н1 можно все сильно сократить.
WH>

WH>tast TypedIf : TypedExpression
WH>for If
WH>{
WH>    ConvertibleTo(condition.ExpressionType, type(bool));
WH>    Unify([trueExpression.ExpressionType, falseExpression.ExpressionType], ExpressionType);
WH>}
WH>

Я вообще не хочу видеть этого мутного кода. А вот сообщения действительно стоило бы улучшить. Но это можно сделать и без лишних действий.

WH>Или можно сделать еще веселее позволить типизироваться по переписанному коду и затаскивать типы от туда.

По сути я это и предлагаю сделать. Возможно ты меня не понял до конца.
Только я предлагаю не заниматься ручной типизации без насущной необходимости. Лучше заставить компилятор выполнять типизацию по требованию (выражаемому в декларативной манере).

WH>Правда, сообщения об ошибках будут такие же мутные как сейчас.

Я же тебе показал как можно решить вопрос с сообщениями об ошибках. Выставляем требования к параметрам макры и в случае их не удовлетворения генерируем сообщение об ошибке. И все это декларативно!

WH>А хинты проясняющие ситуацию придется хардкодить в ядро компилятора...

Ни в коем разе! Это точно не решение.

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

Давно жду.

WH>Вот тогда ты и увидишь насколько твой подход императивен и не расширяем.
WH>Я уже придумал, как сделать foreach расширяемым. Те пользователь сможет добавить специализацию foreach для своих коллекций не трогая основной код и не пересекаясь с другими расширениями.

foreach был расширяем в Н1. Есть, например, версия с otherwise. Так что тут ты Америку не открыл.

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

VD>>Да? Ну, тогда тебе не составит труда конструктивно раскритиковать мое решение.
WH>Ты про ту гору нерасширяемого императива, который наворачивается на императивный типизатор в котором никто ничего не понимает?
WH>

Я демагогию игнорирую.

VD>>Лож. Я привел вполне понятный код который решает задачу и не создает дополнительных проблем, как твой.
WH>Мой код проблем не создает.

Твой код сложный и слишком похож на тот анекдот где самолеты на границе переворачиваются и падают. Он не учитывает кучи нюансов.

VD>>Не, не. Меня не интересует перечисление. Меня интересует псевдокод реализации с комментариями. Реализацию foreach я тебе уже приводил. В прочем, вот она еще раз:
WH>1)Твой код не расширяем.
WH>Попробуй добавить IterateByMyCollectionImpl без изменения макроса foreach.

Хорошая мысль! Только ради нее стоило вести эту беседу!

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

    require: IsTyped(collection) // требуем чтобы перед вызовом тела макроса был типизирован параметр collection

и ручным разбором типов коллекции можно было ввести несколько макросов с одним и тем же синтаксисом, но разными "require". Например, так:

  macro ForEachOnArray : Ast.Expression
    syntax: "foreach" "(" pattern "in" collection ")" body
      where: pattern    = Ast.PatternWithGuard,
             collection = Ast.Expression,
             body       = Ast.Expression;
    require: GetKind(collection.Type) == TypeKind.Array
  {
    <[ /* реализация для массива */ ]>
  }

  macro ForEachOnArray : Ast.Expression
    syntax: "foreach" "(" pattern "in" collection ")" body
      where: pattern    = Ast.PatternWithGuard,
             collection = Ast.Expression,
             body       = Ast.Expression;
    require: GetKind(collection.Type) == TypeKind.IEnumarableT
  {
    <[ /* реализация для IEnumarable[T] */ ]>
  }
...

Причем это будет очень легко реализовать. Все что нужно сделать — это не запрещать полностью идентичные грамматики или грамматики спарсившие одинаковое число символов. А неоднозначность разрешать путем вызова их проверок над типами.

WH>2)Твой код требует чтобы тип коллекции был извествен до того как начнет работать макра.

Ага! И это то что нужно этой макре. Причем типизировать какие-либо другие параметры нельзя, так как до подстановки конечного кода они не смогут успешно стипизироваться. Именно так сегодня и реализован макрос foreach. И никак иначе ты его не сможешь реализовать.

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

WH>А что делать, если тип выводиться на основе тела цикла?

Это невозможно. Тело зависит от типа коллекции. Сейчас делается именно так, и как видишь, foreach работает замечательно.

VD>>То же как типизировать этот код ровным счетом никак не повлияет на наличие в нем "кучу возни на ровном месте".
WH>Повлияет. Никакой возни не будет.

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

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

VD>>Эти проблемы, конечно же, нужно решать. Но я от тебя не слышу предложений по решению этих проблем. Зато вижу апелляцию к вещам не относящимся к делу.
WH>Так если вся типизация будет декларативно описана, то эти проблемы просто не возникнут.

Да, ну? Во как? Вкратце — это не так. Для комплешона нужна отдельная обработка. Необходимость прибегать к использованю паттерн-матчинга по АСТ (без квази-цитирования, КЦ) связана с тем, что при преобразованиях с использованием КЦ теряются локешоны и IDE не может работать корректно. Вот простой пример:

def expr2 = 
  match (expr1)
  {
    | <[ $call(..$parms) ]> => <[ $call(..$parms) ]>
    ...
  };

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

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

WH>В движке будет вся информация.

Опять пустые слова, а нужны объяснения.

WH>Пользователь вообще ничего про IDE во время разработки макросов знать не будет.

Хотелось бы чтобы так было. Но это снова похоже на притчу про самолеты.

WH>Ну разве что если захочет написать рефакторинг.

Жду внятных разъяснений.

VD>>Вот ты затронул тему протаскивания локешонов и местоположения комплита. Так покажи как твое решение будет их решать. Это будет конструктивно.
WH>Т.к. у меня нет трансформаций АСТ во время работы ИДЕ и вся типизация описана декларативно у меня такой проблемы просто не возникнет.

Гы-гы. Твоя схема вообще не жизнеспособна. Как только ты начал хоть немножко задумываться о реальности, то у тебя сразу появились какие-то там transform и т.п.

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

WH>Кодогенератор просто сгенерирует весь нужный код.

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

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

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

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

VD>>Ща мы обсуждая твое сообщение за одно быстренько изучим все что касается Меркури. Это птичий язык который на фиг не уперся. И если ты его приводишь, то будь добр пояснять. Иначе тебя никто не поймет.
WH>Изучить меркури в любом случае полезно.

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

WH>Это очень хороший язык.
WH>http://www.mercury.csse.unimelb.edu.au/information/doc-release/mercury_ref/Determinism-categories.html#Determinism-categories

Охотно верю. Буду очень признателен, если ты (или кто-то еще) опишет что нужно сделать чтобы сделать первые шаги.

Но в контексте данной темы апелляция к Меркури не канает. Это слишком большой барьер. Так что опиши суть этих функций. А еще лучше дай им разумные имена. Чтобы из них была ясна их суть. То что меркури писали очередные ученые которым плевать на то что их язык никто не использует никак не оправдывает тебя.

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

VD>>А как это дело вяжется с выводом типов? Ты еще не забыл, что типы невозможно вывести за один проход?
WH>Отлично.

В лес, такие "аргументы".

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

Ага. Надо. Но ты предлагаешь обратный процесс. Ты предлагаешь порвать мозг еще сильнее.

VD>>Как будет выглядит типизация вызова функции в условиях поддержки языком перегрузки? Мы это тоже заставим делать "пациента"?
WH>Оно будет написано один раз и "пациент" если ему оно понадобиться сможет это использовать.
WH>Хотя зачем ему это может понадобиться не ясно.

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

VD>>А что будем делать с linq который кроме как через такое переписываиние никак не реализуется? Ведь без переписывания мы не сможем вычислить правильны тип. Прочитай внимательно спецификацию C# 3.0:
WH>Хватит уже эту страшилку в сотый раз повторять.
WH>Это решаемая задача.
WH>Я просто думаю, как это сделать получше.

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

VD>>Таким образом твое предложение не проходит критики даже при не глубоком изучении.
WH>Особенно учитывая то, что ты ни слова из написанного не понял...

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

VD>>Во-первых, нужно обосновать необходимость типизации SST.
WH>Да ты на свой ?. посмотри.

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

VD>>Для этого нужно привести хотя бы один пример где типизация по SST дает зримое преимущество над аналогичной реализации без типизации SST.
WH>foreach, lock,...

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

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

WH>А такие макросы как PegGrammar вообще без этого сделать нельзя.
WH>Совсем.
WH>Никак.
WH>Сейчас SST типизируется руками.
WH>Информация для IDE о том, что к чему относиться задается руками.

Опиши как ты это видишь, обсудим. А пока снова вынужден констатировать сотрясение воздуха с твоей стороны.

WH>Автокомплита нет и не предвидеться.

Дык, не продумано было. Вот и нет. Продумаем — будет. Не думаешь же ты, что от того что ты сотрясаешь воздух что-то изменится?

Я согласен, что отсутствие комплита для макросов вроде PegGrammar — это не доработка. Разумно было бы предоставить какие-то средства для организации интеллисенса для подобных ДСЛ-ей. Так же согласен, что гипотетически, можно быть полезно производить типизацию по SST. Но все это можно прекрасно вписать в модель допускающую трасформацию нетипизированного AST.

Более того, я уверен, что перекладывание типизации на плечи писателей макросов в общем случае является ошибкой дизайна. Это усложнит написание макросов и сделает их еще менее доступными для простых смертных. Если сегодня писать макросы мешает кривой API и сложные паттерны, то в твоей схеме появится еще и необходимость типизации там где раньше в ней не было необходимости. Это же так очевидно!

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

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

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

VD>>Пример похоже настолько бредовый, что я него не понял. Что он добивается то?
WH>Чтобы string можно было в if засунуть.

Это типа такой странный способ приведения к булеву типу когда null интерпретируется как false?

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

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

WH>>>pred ConvertibleTo(from : Type, itemType : Type)
WH>>>mode (in, in) is semidet //Проверяет что один тип приводим к другому.
WH>>>mode (in, out) is multi //При помощи бектрекинга перебирает все типы к которым можно привести данный.

VD>>Вот это вот вообще не понятно. "semidet" так просто какое-то шифрование. Что это значит то?

S_S>Выходит что-то типа nullable, или bool
S_S>

S_S>either have no solutions or have one solution, then that mode is semideterministic(semidet);

S_S>Похоже 2 перегрузки, первая принимает 2 параметра и возвращает true/false,
S_S>вторая принимает 1 параметр и возвращает список.

Вот, здорово! Это мы теперь от людей, которые хотят макрос написать, будем требовать изучения разной загробной хрени вроде знания что такое "semideterministic". А чтобы они уж точно макросы не начали писать еще и зашифруем это название в "semidet". Супер!

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

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

Отсечение что ли? И зачем это так шифровать?

WH>>Пролог пошёл лесом, ибо Mercury это пролог сделанный правильно.

C>в чем именно, в контексте вывода типов, Меркюри лучше Пролога?

Меркури лучше Пролога без относительно задач, так как Меркури компилируется в нэйтив-код и статически типизируется.

Вот только на фиг он для вывода типов не нужен. Это перебор. Тут нужен логический ДСЛ. В Н1 используется класс — Solver. Это своего рода микро Меркури. Он поддерживает нужную для вывода типов унификацию.

Можно развить это дело. С одной стороны кроме класса можно было бы завести ДСЛ. С другой кроме подсистему унификации так же было бы разумно завести подсистему описания правил вывода типов и их "решатель". Это позволило бы устранить (или хотя бы уменьшить) объем "рукопашного" кода типизации — основного источника ошибок.

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

VD>Это типа такой странный способ приведения к булеву типу когда null интерпретируется как false?
VD>Пример более чем станный. С этим люди боролись, боролись, а ты решил это как преимущество показать.
Это был всеголишь пример перегрузки макры по типу.
А ты тут разводишь демагогию цепляясь ко всему подряд

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

VD>А это откровенная неправда. Я тебе показал решение которое обеспечивает качественное сообщение об ошибке.
Которое мое вид в профиль.

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

WH>>А хинты проясняющие ситуацию придется хардкодить в ядро компилятора...
VD>Ни в коем разе! Это точно не решение.
Так происходит сейчас.
И ты не предлагаешь никаких механизмов чтобы этого избежать.

VD>foreach был расширяем в Н1. Есть, например, версия с otherwise. Так что тут ты Америку не открыл.
Ты бы почитал о чем я говорю.