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

J>он избавляет от вложенных матчей. представь, что DivisibleBySeven возвращает какой нить сложный объект, который тоже нужно отматчить..
Ну так функции тоже можно использовать во вложенных матчах

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

ВВ>Поэтому, извините, но на мой взгляд от них несет сахарной пудрой.
От почти 100% немерла несет сахороной пудрой.
Но если ее не будет немерле будет страшнее С++са.
Если не веришь отключи все стандартные макросы.
И попробуй пописать на базовом немерле.
Взвоешь минут через 10.

ВВ>Вопрос — что конкретно в актив паттернах на самом деле не является сахаром? Какие случаи вариант Влада покрывать не будет? У меня есть большое подозрение, что такие случаев нет.
В первом сообщении (которое ты так и не прочитал) этих случаев...

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

ВВ>>Поэтому, извините, но на мой взгляд от них несет сахарной пудрой.
WH>От почти 100% немерла несет сахороной пудрой.
WH>Но если ее не будет немерле будет страшнее С++са.
WH>Если не веришь отключи все стандартные макросы.
WH>И попробуй пописать на базовом немерле.
WH>Взвоешь минут через 10.

Я не против пудры. Но пудра должна быть реализована как пудра. Скажем, прекрасно понятно, что "if" это сахар, и он реализован по схеме, аналогичной той, которую сейчас предлагает Влад. Компилятор любезно генерит для тебя немножко кода.

ВВ>>Вопрос — что конкретно в актив паттернах на самом деле не является сахаром? Какие случаи вариант Влада покрывать не будет? У меня есть большое подозрение, что такие случаев нет.
WH>В первом сообщении (которое ты так и не прочитал) этих случаев...

Эти случаи из статьи "что такое актив паттерны и как с ними бороться". Кроме бесконечных конверсий в Integer из строки, можно ли придумать что-то *реально полезное*, что не будет по сути сводиться к разбору объекта по св-вам?

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

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

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

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

[PatternPredicate] IntegerPredicate(obj : string) : bool
{
  mutable intvalue = 0;
  int.TryParse(obj, out intvalue)
}

[PatternSelector] IntegerSelector(obj : string) : bool { int.Parse(obj) }

[PatternPredicate] FloatPredicate(obj : string) : bool
{
  mutable floatvalue = 0;
  float.TryParse(obj, out floatvalue)
}

[PatternSelector] FloatSelector(obj : string) : bool { float.Parse(obj) }

Тогда использование

match(str)
{
  | Integer(i) => $"str : int = $i"
  | Float(f) => $"str : float = $f"
  | _ => $"$str : Not matched"
}

Раскроется следующим образом:

match(str)
{
  | _ when IntegerPredicate(str) => match(IntegerSelector(str)){ | i => $"str : int = $i"}
  | _ when FloatPredicate(str) => match(FloatSelector(str)){ | f => $"str : float = $f"}
  | _ => $"$str : Not matched"
}

option позволяет объединить предикат и селектор в одну функцию и упростить описание правил.

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

Мое дилетантское мнение таково: у матча есть вполне конкретная семантика. Он работает с типами данных и их свойствами (если не считать when-паттерна и встроенной синтактической поддержки списков).

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

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

IT>Думаю, указание базового класса тоже понадобится, т.к. иерархии не всегда плоские.

Насколько я помню для алгоритма построения дерева вывода базовый тип не имеет значений. Код переписывается во что-то вроде:

if (x is Type1) // для каждого объектного паттерна
{
  def boundVar1 = ...;
  def boundVar2 = ...;
  def boundVarN = ...;
  // код обработчика
}
else if (x is Type1)
  ...

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

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

Думаю, что это будет сделать не сложно. Но при этом им придется давать разные имена. Например, для двух вариантов ConditionalExpression можно ввести два конструктора If и When.

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

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

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

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

ВВ>Не совсем. Скажем, обычные паттерны можно представить через when, однако тогда компилятор не будет строить дерево достижимости, проверять, является ли match exhaustive, и все его вхождения станут irrefutable. Т.е. у нас изменится поведение.

Справедливости ради для объектных паттернов достижимость тоже не проверяется.

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

ВВ>Вопрос — что конкретно в актив паттернах на самом деле не является сахаром? Какие случаи вариант Влада покрывать не будет? У меня есть большое подозрение, что такие случаев нет.

Понятно какие! Случае когда эктив-паттерн будет сложной функцией производящей кучу вычислений.

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

VD>Если эти замечательные активные паттерны позволяет объявлять связанные переменные и рекурсивные паттерны внутри них, то это будет больше чем сахар.

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

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

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

ВВ>>Вопрос — что конкретно в актив паттернах на самом деле не является сахаром? Какие случаи вариант Влада покрывать не будет? У меня есть большое подозрение, что такие случаев нет.
VD>Понятно какие! Случае когда эктив-паттерн будет сложной функцией производящей кучу вычислений.

А сделать поддержку выражений — не только разбора по свойствам — в твоем варианте нельзя?

Я бы сказал тут определенно видится этакий макрос, который позволит некрасивые императивные when превратить в красивые декларативный "как бы паттерн".

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

J>Ну и как реюзать конкретный паттерн — не очень понятно.

J>match (someExpr)
J>{
J> | Bin(ExpressionType.And, Const(1), Call(null, method, args)) =>
J> // что-то делаем с method и args
J> | _ => ...
J>}

А в чем тут проблема? И method, и args имеют некоторый тип. Если это объекты, то их опять же можно описать в виде паттернов.

J>допустим мне нужно заюзать в другом месте аналогичный паттерн, мне его полностью копировать??

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

Если речь об одной сборке, то объявление будет видно во всей сборке.


J>в F# можно было бы так написать:

J>let (|ExpressionOneAndStaticMethodCall|_|) = function
J> | Bin(ExpressionType.And, Const(1), Call(null, method, args)) -> Some (method, args)
J> | None

J>И потом юзать где нуно:
J>match exp
J>| ExpressionOneAndStaticMethodCall (method, args) ->
J>| ... -> ...

Ой ли? И в другой сборке? Если это так, то на лицо нарушение сокрытия объектов, так как мы не указывали public для данной конструкции.

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

ВВ>>Поэтому, извините, но на мой взгляд от них несет сахарной пудрой.
WH>От почти 100% немерла несет сахороной пудрой.
WH>Но если ее не будет немерле будет страшнее С++са.
WH>Если не веришь отключи все стандартные макросы.
WH>И попробуй пописать на базовом немерле.
WH>Взвоешь минут через 10.

+1

ВВ>>Вопрос — что конкретно в актив паттернах на самом деле не является сахаром? Какие случаи вариант Влада покрывать не будет? У меня есть большое подозрение, что такие случаев нет.
WH>В первом сообщении (которое ты так и не прочитал) этих случаев...

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

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

ВВ>>Не совсем. Скажем, обычные паттерны можно представить через when, однако тогда компилятор не будет строить дерево достижимости, проверять, является ли match exhaustive, и все его вхождения станут irrefutable. Т.е. у нас изменится поведение.
VD>Справедливости ради для объектных паттернов достижимость тоже не проверяется.

Не строит, потому что просто нереализовано или есть какие-то принципиальные проблемы, которые делают это нереализуемым?

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

VD>>Если эти замечательные активные паттерны позволяет объявлять связанные переменные и рекурсивные паттерны внутри них, то это будет больше чем сахар.

ВВ>Позволяют. Но все равно это сахар.

Да что ты прицепился к этому сахару?
Считать что-то сахаром/не сахаром — это вопрос философский важно только полезна ли фича и насколько сложно ее реализовать.

ВВ>Собственно, рекурсию и биндинг можно выразить и через when — если я правильно понял твой вариант, он это позволяет.

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

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

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

Любую логику можно реализовать на when. Так что по твоим канонам все есть сахар.

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

ВВ>А сделать поддержку выражений — не только разбора по свойствам — в твоем варианте нельзя?

А что ты понимаешь под выражениями? В немерле вообще-то ПМ только по данным работает.

ВВ>Я бы сказал тут определенно видится этакий макрос, который позволит некрасивые императивные when превратить в красивые декларативный "как бы паттерн".

Это уже какой-то очень сложный макрос. Такое поведение лучше все же в компилятор засовывать.

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

ВВ>Не строит, потому что просто нереализовано или есть какие-то принципиальные проблемы, которые делают это нереализуемым?

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

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

VD>Да что ты прицепился к этому сахару?
VD>Считать что-то сахаром/не сахаром — это вопрос философский важно только полезна ли фича и насколько сложно ее реализовать.

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

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

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

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

ВВ>>А сделать поддержку выражений — не только разбора по свойствам — в твоем варианте нельзя?
VD>А что ты понимаешь под выражениями? В немерле вообще-то ПМ только по данным работает.

Я имел в виду генерить сложные expression-ы для when на основе более простой декларативной записи. Но, видимо, так не выйдет.

Здравствуйте, Рысцов Денис, Вы писали:

Float/Integer это все хорошо. Но честно говоря я в вашем примере вижу как то, что *не является* паттерном зачем-то выглядит как паттерн. Поведение при этом — такое же как у when. Например, если бы происходил парсинг и сравнение значение, то мы бы могли успешно "сопоставиться" с паттером Integer, однако сравнение не прошло бы, потом бы мы успешно "сопоставились" с Float и пр. В вашем примере — разбираемое значение одновременно может подходить и под Integer и под Float. Компилятор молчит, анализа достижимости нет. Переставьте местами Float и Integer — будет ворнинг?

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

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