Respuesta corta:
El operador de comillas es un operador que induce semántica de cierre en su operando . Las constantes son solo valores.
Las comillas y las constantes tienen diferentes significados y, por lo tanto, tienen diferentes representaciones en un árbol de expresión . Tener la misma representación para dos cosas muy diferentes es extremadamente confuso y propenso a errores.
Respuesta larga:
Considera lo siguiente:
(int s)=>(int t)=>s+t
La lambda externa es una fábrica de sumadores que están vinculados al parámetro de la lambda externa.
Ahora, supongamos que deseamos representar esto como un árbol de expresión que luego se compilará y ejecutará. ¿Cuál debería ser el cuerpo del árbol de expresión? Depende de si desea que el estado compilado devuelva un delegado o un árbol de expresión.
Comencemos por descartar el caso poco interesante. Si deseamos que devuelva un delegado, entonces la cuestión de si usar Quote o Constant es un punto discutible:
var ps = Expression.Parameter(typeof(int), "s");
var pt = Expression.Parameter(typeof(int), "t");
var ex1 = Expression.Lambda(
Expression.Lambda(
Expression.Add(ps, pt),
pt),
ps);
var f1a = (Func<int, Func<int, int>>) ex1.Compile();
var f1b = f1a(100);
Console.WriteLine(f1b(123));
La lambda tiene una lambda anidada; el compilador genera la lambda interior como un delegado de una función cerrada sobre el estado de la función generada para la lambda exterior. No necesitamos considerar este caso más.
Supongamos que deseamos que el estado compilado devuelva un árbol de expresión del interior. Hay dos formas de hacerlo: la forma fácil y la forma difícil.
La manera difícil es decir que en lugar de
(int s)=>(int t)=>s+t
lo que realmente queremos decir es
(int s)=>Expression.Lambda(Expression.Add(...
Y luego genere el árbol de expresión para eso , produciendo este lío :
Expression.Lambda(
Expression.Call(typeof(Expression).GetMethod("Lambda", ...
bla, bla, bla, docenas de líneas de código de reflexión para hacer la lambda. El propósito del operador de comillas es decirle al compilador del árbol de expresiones que queremos que la lambda dada sea tratada como un árbol de expresión, no como una función, sin tener que generar explícitamente el código de generación del árbol de expresión .
La forma fácil es:
var ex2 = Expression.Lambda(
Expression.Quote(
Expression.Lambda(
Expression.Add(ps, pt),
pt)),
ps);
var f2a = (Func<int, Expression<Func<int, int>>>)ex2.Compile();
var f2b = f2a(200).Compile();
Console.WriteLine(f2b(123));
Y de hecho, si compila y ejecuta este código, obtiene la respuesta correcta.
Observe que el operador de comillas es el operador que induce la semántica de cierre en la lambda interior que usa una variable externa, un parámetro formal de la lambda externa.
La pregunta es: ¿por qué no eliminar Quote y hacer que esto haga lo mismo?
var ex3 = Expression.Lambda(
Expression.Constant(
Expression.Lambda(
Expression.Add(ps, pt),
pt)),
ps);
var f3a = (Func<int, Expression<Func<int, int>>>)ex3.Compile();
var f3b = f3a(300).Compile();
Console.WriteLine(f3b(123));
La constante no induce semántica de cierre. ¿Por qué debería hacerlo? Dijiste que esto era una constante . Es solo un valor. Debería ser perfecto cuando se entregó al compilador; el compilador debería poder generar un volcado de ese valor en la pila donde sea necesario.
Dado que no se induce un cierre, si hace esto, obtendrá una excepción "variable 's' de tipo 'System.Int32' no está definida" en la invocación.
(Aparte: acabo de revisar el generador de código para la creación de delegados a partir de árboles de expresión entre comillas, y desafortunadamente un comentario que puse en el código en 2006 todavía está allí. Para su información, el parámetro externo elevado se captura en una constante cuando se cita El árbol de expresión se reifica como un delegado por el compilador en tiempo de ejecución.Había una buena razón por la que escribí el código de esa manera que no recuerdo en este momento exacto, pero tiene el desagradable efecto secundario de introducir cierre sobre valores de parámetros externos en lugar de cierre sobre variables. Aparentemente, el equipo que heredó ese código decidió no corregir ese defecto, por lo que si confía en la mutación de un parámetro externo cerrado que se observa en una lambda interior citada compilada, se sentirá decepcionado. Sin embargo, dado que es una práctica de programación bastante mala tanto (1) mutar un parámetro formal como (2) depender de la mutación de una variable externa, le recomendaría que cambie su programa para no usar estas dos prácticas de programación malas, en lugar de esperando una solución que no parece estar disponible. Disculpas por el error.)
Entonces, para repetir la pregunta:
El compilador de C # podría haberse hecho para compilar expresiones lambda anidadas en un árbol de expresión que involucre Expression.Constant () en lugar de Expression.Quote (), y cualquier proveedor de consultas LINQ que desee procesar árboles de expresión en algún otro lenguaje de consulta (como SQL ) podría buscar una ConstantExpression con el tipo Expression en lugar de una UnaryExpression con el tipo de nodo Quote especial, y todo lo demás sería igual.
Estás en lo correcto. Nos podríamos codificar la información semántica que significa "inducen la semántica de cierre de este valor" por el uso del tipo de la expresión de la constante como una bandera .
"Constante" tendría entonces el significado "use este valor constante, a menos que el tipo sea un tipo de árbol de expresión y el valor sea un árbol de expresión válido, en cuyo caso, use en su lugar el valor que es el árbol de expresión resultante de reescribir el interior del árbol de expresión dado para inducir la semántica de cierre en el contexto de cualquier lambda exterior en el que podríamos estar ahora.
Pero ¿por qué tendríamos que hacer esa cosa loca? El operador de cotización es un operador increíblemente complicado y debe usarse explícitamente si lo va a usar. Está sugiriendo que para ser parsimoniosos al no agregar un método de fábrica adicional y un tipo de nodo entre las varias docenas que ya existen, agreguemos un extraño caso de esquina a las constantes, de modo que las constantes a veces sean lógicamente constantes, y a veces se reescriban lambdas con semántica de cierre.
También tendría el efecto algo extraño de que constante no significa "usar este valor". Suponga que, por alguna extraña razón, desea que el tercer caso anterior compile un árbol de expresión en un delegado que distribuya un árbol de expresión que tenga una referencia no reescrita a una variable externa. ¿Por qué? Quizás porque está probando su compilador y simplemente desea pasar la constante para poder realizar algún otro análisis más adelante. Su propuesta lo haría imposible; cualquier constante que sea del tipo árbol de expresión se reescribirá independientemente. Uno tiene una expectativa razonable de que "constante" significa "usar este valor". "Constante" es un nodo "haz lo que digo". El procesador constante ' decir basado en el tipo.
Y tenga en cuenta, por supuesto, que ahora está poniendo la carga de la comprensión (es decir, la comprensión de que constante tiene una semántica complicada que significa "constante" en un caso e "induce una semántica de cierre" basada en una bandera que está en el sistema de tipos ) sobre cada proveedor que realiza análisis semántico de un árbol de expresión, no solo de proveedores de Microsoft. ¿Cuántos de esos proveedores externos se equivocarían?
"Quote" agita una gran bandera roja que dice "Hey amigo, mira aquí, soy una expresión lambda anidada y tengo una semántica loca si estoy cerrado sobre una variable externa". mientras que "Constante" está diciendo "No soy más que un valor; úsame como mejor te parezca". Cuando algo es complicado y peligroso, queremos hacer que ondee banderas rojas, sin ocultar ese hecho haciendo que el usuario busque en el sistema de tipos para averiguar si este valor es especial o no.
Además, la idea de que evitar la redundancia es incluso un objetivo es incorrecta. Claro, evitar la redundancia innecesaria y confusa es un objetivo, pero la mayoría de la redundancia es algo bueno; la redundancia crea claridad. Los nuevos métodos de fábrica y tipos de nodos son baratos . Podemos hacer tantas como necesitemos para que cada una represente una operación limpiamente. No tenemos necesidad de recurrir a trucos desagradables como "esto significa una cosa a menos que este campo esté configurado para esta cosa, en cuyo caso significa otra cosa".