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

V>>Соответственно, Y-комбинатор является костылём для тех языков, в которых замыкания могут быть только анонимными.
V>>Но в C# замыканиям можно давать имя.
V>>Поэтому, Y-костыль в C# не нужен.
I>Попробуй свои примерчики применить на IQueryable.

Выглядит как эпик слив, аднака.
Твои слова:

Expression это определенные ограничения, которые позволяют легко транслировать код и одновременно внятный конвеншн для сообщества.
...
Есть тут имя или нет, дело абсолютно десятое. Но вот для рекурсии все становится иначе — и все ради этого самого экспрешна, что бы легко было анализировать, транслировать, выводить тип и тд и тд.

?

Разбираем:

— экспрешшены нужны потому что дерево выражений не может выразить стейтменты, а только экпрешшены.
Ложь, обычные выражения тоже понимает хорошо: Expression.AssAssign(...), BlockExpression и т.д. до бесконечности — все операторы выражения языка C# прекрасно понимаются;

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

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

И даже в таком виде многие реализации Querable-провайдеров "не понимают" и половины выражений, которые для них может составить линк.
Это проблема IQueryable? — нет, это проблема ограничений реализации или принципиальных ограничений конкретных провайдеров.

Можно ли генерить батчи с переменными на Linq, где будут не только запросы, но и манипуляция переменными? — можно запросто.
Можно ли написать провайдер, который будет автоматически преобразовывать рекурсивные запросы в CTE? — ничто не запрещает.

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


V>>C# не умеет инлайнить тела делегатов, поэтому для него злоупотребление такой техникой является банальной глупостью. Невежеством.
I>Ну вот ты сам себе ответил еще раз — C# чего то не умеет. Как следствие — Linq этого тоже умеет.

Очередной эпик. ))
Linq в варианте IQueryable, напротив, вместо тел делегатов генерит их AST.


V>>Non-pure ф-ии в C# не отличимы от pure, поэтому эти два кейза неотличимы.
I>В огороде бузина, а в Киеве дядька.

Еще и не понимаем, что через "чистый" вызов ф-ии можно делать "грязные" дела.


I>Моя цель показать тебе, что все возможные решения приводят к простыням и дополнительным проблемам.

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


I>Разница только в том, что ты считаешь свой подход классным и применимым, а я это считаю ни разу не классным и неприменимым.

Э, нет.
Разница в том, что я показываю и показываю — что, почему и как.
А у тебя сплошное "А баба Яга против!"

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

V>>Соответственно, Y-комбинатор является костылём для тех языков, в которых замыкания могут быть только анонимными.
V>>Но в C# замыканиям можно давать имя.
V>>Поэтому, Y-костыль в C# не нужен.
I>Попробуй свои примерчики применить на IQueryable.

Выглядит как эпик слив, аднака.
Твои слова:

Expression это определенные ограничения, которые позволяют легко транслировать код и одновременно внятный конвеншн для сообщества.
...
Есть тут имя или нет, дело абсолютно десятое. Но вот для рекурсии все становится иначе — и все ради этого самого экспрешна, что бы легко было анализировать, транслировать, выводить тип и тд и тд.

?

Разбираем:

— экспрешшены нужны потому что дерево выражений не может выразить стейтменты, а только экпрешшены.
Ложь, обычные выражения тоже понимает хорошо: Expression.AssAssign(...), BlockExpression и т.д. до бесконечности — все операторы выражения языка C# прекрасно понимаются;

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

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

И даже в таком виде многие реализации Querable-провайдеров "не понимают" и половины выражений, которые для них может составить линк.
Это проблема IQueryable? — нет, это проблема ограничений реализации или принципиальных ограничений конкретных провайдеров.

Можно ли генерить батчи с переменными на Linq, где будут не только запросы, но и манипуляция переменными? — можно запросто.
Можно ли написать провайдер, который будет автоматически преобразовывать рекурсивные запросы в CTE? — ничто не запрещает.

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


V>>C# не умеет инлайнить тела делегатов, поэтому для него злоупотребление такой техникой является банальной глупостью. Невежеством.
I>Ну вот ты сам себе ответил еще раз — C# чего то не умеет. Как следствие — Linq этого тоже умеет.

Очередной эпик. ))
Linq в варианте IQueryable, напротив, вместо тел делегатов генерит их AST.


V>>Non-pure ф-ии в C# не отличимы от pure, поэтому эти два кейза неотличимы.
I>В огороде бузина, а в Киеве дядька.

Еще и не понимаем, что через "чистый" вызов ф-ии можно делать "грязные" дела.


I>Моя цель показать тебе, что все возможные решения приводят к простыням и дополнительным проблемам.

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


I>Разница только в том, что ты считаешь свой подход классным и применимым, а я это считаю ни разу не классным и неприменимым.

Э, нет.
Разница в том, что я рассказываю и показываю — что, почему и как.
А у тебя сплошное "А баба Яга против!"