En informática, el azúcar sintáctico es una sintaxis dentro de un lenguaje de programación que está diseñado para facilitar la lectura o la expresión. Hace que el lenguaje sea más "dulce" para el uso humano: las cosas se pueden expresar de forma más clara, más concisa o en un estilo alternativo que algunos prefieran.
Por ejemplo, muchos lenguajes de programación proporcionan una sintaxis especial para referenciar y actualizar elementos de matriz. De manera abstracta, una referencia de matriz es un procedimiento de dos argumentos: una matriz y un vector de subíndice, que podría expresarse como get_array(Array, vector(i,j)). En cambio, muchos lenguajes proporcionan sintaxis como Array[i,j]. De manera similar, la actualización de un elemento de matriz es un procedimiento que consta de tres argumentos, por ejemplo set_array(Array, vector(i,j), value), pero muchos lenguajes proporcionan una sintaxis como Array[i,j] = value.
Un constructo en un lenguaje es azúcar sintáctico si se puede eliminar del lenguaje sin ningún efecto sobre lo que puede hacer el lenguaje: la funcionalidad y el poder expresivo seguirán siendo los mismos.
Los procesadores de lenguaje, incluidos los compiladores y los analizadores estáticos, a menudo expanden las construcciones azucaradas en construcciones más fundamentales antes del procesamiento, un proceso que a veces se denomina "desazucaración".
El término azúcar sintáctico fue acuñado por Peter J. Landin en 1964 para describir la sintaxis superficial de un lenguaje de programación simple similar a ALGOL que se definía semánticamente en términos de las expresiones aplicativas del cálculo lambda, centrado en la sustitución léxica de λ por "dónde".
Los lenguajes de programación posteriores, como CLU, ML y Scheme, ampliaron el término para referirse a la sintaxis dentro de un lenguaje que podría definirse en términos de un núcleo de lenguaje de construcciones esenciales; las características convenientes de nivel superior podrían "desazucararse" y descomponerse en ese subconjunto. Ésta es, de hecho, la práctica matemática habitual de construir a partir de primitivas.
Sobre la base de la distinción de Landin entre las construcciones esenciales del lenguaje y el azúcar sintáctico, en 1991, Matthias Felleisen propuso una codificación del "poder expresivo" para alinearse con las "creencias generalizadas" en la literatura. Definió "más expresivo" en el sentido de que sin las construcciones del lenguaje en cuestión, un programa tendría que reorganizarse por completo.
MOVE A B.y la oración MOVE A TO B.realizan exactamente la misma función, pero la segunda aclara la acción a realizar.a += bes equivalente a a = a + ben C y lenguajes similares, asumiendo que ano tiene efectos secundarios como si aes una variable regular. Algunos lenguajes, como Python, pueden permitir la sobrecarga de operadores de asignación aumentada, por lo que pueden comportarse de manera diferente a los estándar.unless (condition) {...}es azúcar sintáctico para if (not condition) {...}. Además, cualquier declaración puede ir seguida de una condición, por lo que statement if conditiones equivalente a if (condition) {statement}, pero la primera tiene un formato más natural en una sola línea.a[i]notación es azúcar sintáctica para *(a + i). Asimismo, la a-gt;xnotación es azúcar sintáctica para acceder a miembros utilizando el operador de desreferencia (*a).x.usingdeclaración en C # asegura que ciertos objetos se eliminen correctamente. El compilador expande la declaración en un bloque de prueba finalmente.var x = expr, lo que permite al compilador inferir el tipo de xde la expresión expr, en lugar de requerir una declaración de tipo explícita. Del mismo modo, C ++ permite auto x = exprdesde C ++ 11 y Java permite var x = exprdesde Java 11.[x*x for x in range(10)]una lista de cuadrados) y decoradores (como @staticmethod).%gt;%, declara que los datos (o la salida de la función) que preceden a la tubería servirán como primer argumento para la función que sigue a la tubería. Entonces, x %gt;% f(y)es equivalente a f(x,y).JOINes equivalente a INNER JOIN, este último aclara que la declaración de combinación es específicamente una operación de combinación interna en lugar de una operación de combinación externa.myObject.myMethod(parameter1, parameter2, parameter3)es azúcar sintáctico para llamar a una función global como. La referencia al objeto se pasa como un argumento oculto, generalmente accesible desde dentro del método como.myMethod(myObject, parameter1, parameter2, parameter3)thisimportdeclaración permite al compilador encontrar clases que no se especifican de otra manera con nombres completos. Por ejemplo, import javax.swing.*;permite al programador hacer referencia a un objeto Swing, como javax.swing.JButtonusar el nombre más corto JButton.Algunos programadores sienten que estas características de usabilidad de la sintaxis no son importantes o son completamente frívolas. En particular, las formas sintácticas especiales hacen que un lenguaje sea menos uniforme y su especificación más compleja, y pueden causar problemas a medida que los programas se vuelven grandes y complejos. Esta vista está particularmente extendida en la comunidad Lisp, ya que Lisp tiene una sintaxis muy simple y regular, y la sintaxis superficial se puede modificar fácilmente. Por ejemplo, Alan Perlis bromeó una vez en " Epigramas sobre programación ", en una referencia a los lenguajes delimitados por corchetes, que "el azúcar sintáctico causa cáncer de punto y coma ".
La metáfora se ha ampliado al acuñar el término sal sintáctica, que indica una característica diseñada para dificultar la escritura de código incorrecto. Específicamente, la sal sintáctica es un aro que los programadores deben atravesar solo para demostrar que saben lo que está sucediendo, en lugar de expresar una acción del programa. Por ejemplo, en Java y Pascal, asignar un valor flotante a una variable declarada como un int sin una sintaxis adicional que indique explícitamente esa intención resultará en un error de compilación, mientras que C y C ++ truncarán automáticamente cualquier flotante asignado a un int. Sin embargo, esto no es sintaxis, sino semántica.
En C #, al ocultar un miembro de clase heredado, se emite una advertencia del compilador a menos que se use la newpalabra clave para especificar que el ocultamiento es intencional. Para evitar errores potenciales debido a la similitud de la sentencia switch de sintaxis con el de C o C ++, C # requiere una breakpara cada una no vacía caseetiqueta de un switch(a no ser que goto , returno throwse usa) a pesar de que no permite implícita de paso al siguiente. (Usando gotoy especificando la etiqueta posterior produce una C / C ++ - como caída-a través.)
La sal sintáctica puede frustrar su propósito al hacer que el código sea ilegible y, por lo tanto, empeorar su calidad; en casos extremos, la parte esencial del código puede ser más corta que la sobrecarga introducida para satisfacer los requisitos del lenguaje.
Una alternativa a la sal sintáctica es generar advertencias del compilador cuando existe una alta probabilidad de que el código sea el resultado de un error, una práctica común en los compiladores modernos de C / C ++.
Otras extensiones son la sacarina sintáctica y el jarabe sintáctico , es decir, una sintaxis gratuita que no facilita la programación.
Se dice que los tipos de datos con soporte sintáctico central son "tipos azucarados". Los ejemplos comunes incluyen cadenas delimitadas por comillas, llaves para objetos y tipos de registro y corchetes para matrices.
|journal=( ayuda )