Сообщение Re[72]: MS забило на дотнет. Питону - да, сишарпу - нет? от 13.09.2021 17:42
Изменено 13.09.2021 20:12 vdimas
Re[72]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
S>При этом этот add2 — это вовсе не вызов того же add с b=2, а по честному проинлайненный код делегата, соответствующий a=>a+2.
S>Для Expression это, понятное дало, тривиальное упражнение. А интересно, конечно, делать это для готовых делегатов.
Восстанавливать из тела делегата Expression, как это делает Reflector и другие подобные тулзы. ))
S>А уже потом поверх такой библиотеки можно делать различные прикольные плюшки типа "а давайте оптимизируем нашу цепочку цепочек делегатов".
Ес-но.
S>Но это всё тоже требует больших затрат
Ну вот, задача сформулирована — восстанавливать Expression из CIL.
S>Например, хорошо известная штука — в Expressions до сих пор нет поддержки Tuple Initializer или как он там называется.
S>То есть нельзя сделать
S>
S>Можно только
S>
S>Хотя казалось бы — чего такого-то?
У меня вот так ругается:
Вот так нет:
А как вообще сюда напишешь расширение, если Expression порождаем сам компилятор?
Я еще понимаю написать расширения к уже готовым экземплярам Expression...
Ниже вообще для меня новости.
Вот так ОК:
Вот так нельзя:
Т.е. блоки для Expression нельзя.
Можно так:
=================
Кароч, там еще пилить и пилить...
S>При этом этот add2 — это вовсе не вызов того же add с b=2, а по честному проинлайненный код делегата, соответствующий a=>a+2.
S>Для Expression это, понятное дало, тривиальное упражнение. А интересно, конечно, делать это для готовых делегатов.
Восстанавливать из тела делегата Expression, как это делает Reflector и другие подобные тулзы. ))
S>А уже потом поверх такой библиотеки можно делать различные прикольные плюшки типа "а давайте оптимизируем нашу цепочку цепочек делегатов".
Ес-но.
S>Но это всё тоже требует больших затрат
Ну вот, задача сформулирована — восстанавливать Expression из CIL.
S>Например, хорошо известная штука — в Expressions до сих пор нет поддержки Tuple Initializer или как он там называется.
S>То есть нельзя сделать
S>
S>Expression<Func<int, (int, int)>> t = a=>(a, a);
S>S>Можно только
S>
S>Expression<Func<int, (int, int)>> t = a=>Tuple.Create(a, a);
S>S>Хотя казалось бы — чего такого-то?
У меня вот так ругается:
Expression<Func<int, (int, int)>> t = a => Tuple.Create(a, a);Вот так нет:
Expression<Func<int, Tuple<int, int>>> t2 = a => Tuple.Create(a, a);А как вообще сюда напишешь расширение, если Expression порождаем сам компилятор?
Я еще понимаю написать расширения к уже готовым экземплярам Expression...
Ниже вообще для меня новости.
Вот так ОК:
Func<int, int> f = a => {
return a;
};Вот так нельзя:
Expression<Func<int, int>> t3 = a => {
return a;
};Т.е. блоки для Expression нельзя.
Можно так:
Expression<Func<int, int>> t4 = a => a;=================
Кароч, там еще пилить и пилить...
Re[72]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
S>При этом этот add2 — это вовсе не вызов того же add с b=2, а по честному проинлайненный код делегата, соответствующий a=>a+2.
S>Для Expression это, понятное дало, тривиальное упражнение. А интересно, конечно, делать это для готовых делегатов.
Восстанавливать из тела делегата Expression, как это делает Reflector и другие подобные тулзы. ))
S>А уже потом поверх такой библиотеки можно делать различные прикольные плюшки типа "а давайте оптимизируем нашу цепочку цепочек делегатов".
Ес-но.
S>Но это всё тоже требует больших затрат
Ну вот, задача сформулирована — восстанавливать Expression из CIL.
S>Например, хорошо известная штука — в Expressions до сих пор нет поддержки Tuple Initializer или как он там называется.
S>То есть нельзя сделать
S>
S>Можно только
S>
S>Хотя казалось бы — чего такого-то?
У меня вот так ругается:
Вот так нет:
А как вообще сюда напишешь расширение, если Expression порождает сам компилятор?
Я еще понимаю написать расширения к уже готовым экземплярам Expression...
Ниже вообще для меня новости.
Вот так ОК:
Вот так нельзя:
Т.е. блоки для Expression нельзя.
Можно так:
=================
Кароч, там еще пилить и пилить...
S>При этом этот add2 — это вовсе не вызов того же add с b=2, а по честному проинлайненный код делегата, соответствующий a=>a+2.
S>Для Expression это, понятное дало, тривиальное упражнение. А интересно, конечно, делать это для готовых делегатов.
Восстанавливать из тела делегата Expression, как это делает Reflector и другие подобные тулзы. ))
S>А уже потом поверх такой библиотеки можно делать различные прикольные плюшки типа "а давайте оптимизируем нашу цепочку цепочек делегатов".
Ес-но.
S>Но это всё тоже требует больших затрат
Ну вот, задача сформулирована — восстанавливать Expression из CIL.
S>Например, хорошо известная штука — в Expressions до сих пор нет поддержки Tuple Initializer или как он там называется.
S>То есть нельзя сделать
S>
S>Expression<Func<int, (int, int)>> t = a=>(a, a);
S>S>Можно только
S>
S>Expression<Func<int, (int, int)>> t = a=>Tuple.Create(a, a);
S>S>Хотя казалось бы — чего такого-то?
У меня вот так ругается:
Expression<Func<int, (int, int)>> t = a => Tuple.Create(a, a);Вот так нет:
Expression<Func<int, Tuple<int, int>>> t2 = a => Tuple.Create(a, a);А как вообще сюда напишешь расширение, если Expression порождает сам компилятор?
Я еще понимаю написать расширения к уже готовым экземплярам Expression...
Ниже вообще для меня новости.
Вот так ОК:
Func<int, int> f = a => {
return a;
};Вот так нельзя:
Expression<Func<int, int>> t3 = a => {
return a;
};Т.е. блоки для Expression нельзя.
Можно так:
Expression<Func<int, int>> t4 = a => a;=================
Кароч, там еще пилить и пилить...