Сообщение Re[60]: The door от 20.07.2018 16:16
Изменено 20.07.2018 16:16 vdimas
Re[60]: The door
Здравствуйте, Ikemefula, Вы писали:
V>>Соответственно, Y-комбинатор является костылём для тех языков, в которых замыкания могут быть только анонимными.
V>>Но в C# замыканиям можно давать имя.
V>>Поэтому, Y-костыль в C# не нужен.
I>Попробуй свои примерчики применить на IQueryable.
Выглядит как эпик слив, аднака.
Твои слова:
Разбираем:
— экспрешшены нужны потому что дерево выражений не может выразить стейтменты, а только экпрешшены.
Ложь, понимает хорошо: 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>Разница только в том, что ты считаешь свой подход классным и применимым, а я это считаю ни разу не классным и неприменимым.
Э, нет.
Разница в том, что я показываю и показываю — что, почему и как.
А у тебя сплошное "А баба Яга против!"
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>Разница только в том, что ты считаешь свой подход классным и применимым, а я это считаю ни разу не классным и неприменимым.
Э, нет.
Разница в том, что я показываю и показываю — что, почему и как.
А у тебя сплошное "А баба Яга против!"
Re[60]: The door
Здравствуйте, Ikemefula, Вы писали:
V>>Соответственно, Y-комбинатор является костылём для тех языков, в которых замыкания могут быть только анонимными.
V>>Но в C# замыканиям можно давать имя.
V>>Поэтому, Y-костыль в C# не нужен.
I>Попробуй свои примерчики применить на IQueryable.
Выглядит как эпик слив, аднака.
Твои слова:
Разбираем:
— экспрешшены нужны потому что дерево выражений не может выразить стейтменты, а только экпрешшены.
Ложь, обычные выражения тоже понимает хорошо: 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>Разница только в том, что ты считаешь свой подход классным и применимым, а я это считаю ни разу не классным и неприменимым.
Э, нет.
Разница в том, что я показываю и показываю — что, почему и как.
А у тебя сплошное "А баба Яга против!"
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>Разница только в том, что ты считаешь свой подход классным и применимым, а я это считаю ни разу не классным и неприменимым.
Э, нет.
Разница в том, что я показываю и показываю — что, почему и как.
А у тебя сплошное "А баба Яга против!"