En informática , el azúcar sintáctico es la sintaxis dentro de un lenguaje de programación que está diseñada para hacer que las cosas sean más fáciles de leer o expresar. Hace que el lenguaje sea "más dulce" para el uso humano: las cosas pueden expresarse de manera más clara, más concisa o en un estilo alternativo que algunos prefieran. El azúcar sintáctico suele ser una abreviatura de una operación común que también podría expresarse en una forma alternativa y más detallada: el programador tiene la opción de utilizar la forma más corta o la forma más larga, pero normalmente utilizará la forma más corta ya que es más corto y más fácil de escribir y leer.
Por ejemplo, muchos lenguajes de programación proporcionan una sintaxis especial para hacer referencia y actualizar elementos de matriz . De manera abstracta, una referencia a una 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, una 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 también proporcionan una sintaxis como Array[i,j] = value.
Una construcción en un idioma es azúcar sintáctica si se puede eliminar del idioma sin ningún efecto sobre lo que el idioma puede hacer: la funcionalidad y el poder expresivo seguirán siendo los mismos.
Los procesadores de lenguaje, incluidos los compiladores y analizadores estáticos , a menudo expanden las construcciones azucaradas a sus equivalentes más detallados antes del procesamiento, un proceso a veces llamado "desazucarado".
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 tipo ALGOL que se definió semánticamente en términos de las expresiones aplicativas del cálculo lambda , [1] [2] centrado en reemplazar léxicamente λ con "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 "desazucarse" y descomponerse en ese subconjunto. [3] Esta es, de hecho, la práctica matemática habitual de construir a partir de primitivas.
Basándose en la distinción de Landin entre construcciones lingüísticas esenciales y azúcar sintáctico, en 1991, Matthias Felleisen propuso una codificación del "poder expresivo" para alinearse con las "creencias ampliamente extendidas" 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. [4]
MOVE A B.y la oración MOVE A TO B.realizan exactamente la misma función, pero la segunda deja más clara la acción a realizar.a += bes equivalente a a = a + ben C y lenguajes similares, asumiendo que ano tiene efectos secundarios como si afuera una variable regular. [5] [6] Algunos lenguajes, como Python [7], 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). [8] Asimismo, la a->xnotación es azúcar sintáctica para acceder a miembros utilizando el operador de desreferencia (*a).x .usingdeclaración en C# garantiza que ciertos objetos se eliminen correctamente. El compilador expande la declaración en un bloque try-finally . [9]var x = expr, lo que permite al compilador inferir el tipo de xla expresión expr, en lugar de requerir una declaración de tipo explícita. De manera similar, C++ lo permite auto x = exprdesde C++ 11 y Java lo permite var x = exprdesde Java 11.[x*x for x in range(10)]para una lista de cuadrados) y decoradores (como @staticmethod).%>%, 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. [10] Entonces, x %>% f(y)es equivalente a f(x,y).JOINes equivalente a an INNER JOIN, este último aclara que la declaración de unión es específicamente una operación de unión interna en lugar de una operación de unión externa. Asimismo, se pueden omitir el OUTERde LEFT OUTER JOIN, RIGHT OUTER JOINy FULL OUTER JOIN.myObject.myMethod(parameter1, parameter2, parameter3)azúcar sintáctico para llamar a una función global como . La referencia al objeto se pasa como un argumento oculto, normalmente accesible desde el método como .myMethod(myObject, parameter1, parameter2, parameter3)thisimportdeclaración permite al compilador encontrar clases que de otro modo no están especificadas con nombres completos. Por ejemplo, import javax.swing.*;permite al programador hacer referencia a un objeto Swing , como por ejemplo javax.swing.JButtonutilizando el nombre más corto JButton.(x) => x + 1, que es equivalente a la forma más larga (x) => { return x + 1; }. ??? ) equivalen a throw new NotImplementedError . Esto resulta útil para marcar un lugar para el código que aún no se ha escrito. [11]Algunos programadores sienten que estas características de usabilidad de 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 visión 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. [12] Por ejemplo, Alan Perlis bromeó una vez en " Epigramas sobre programación ", en una referencia a lenguajes delimitados por corchetes , que "el azúcar sintáctico causa cáncer de punto y coma ". [13]
La metáfora se ha ampliado acuñando el término sal sintáctica , que indica una característica diseñada para dificultar la escritura de código incorrecto. [14] 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.
En C# , cuando se oculta un miembro de clase heredado, se emite una advertencia del compilador a menos que newse use la palabra clave para especificar que la ocultación es intencional. [15] Para evitar posibles errores debido a la similitud de la sintaxis de la declaración de cambio con la de C o C++, C# requiere una para cada etiqueta breakno vacía de a (a menos que se use , o ), aunque no permite la caída implícita. -a través de . [16] (El uso y especificación de la etiqueta posterior produce un error similar a C/C++ ).caseswitchgotoreturnthrowgoto
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 al salt sintáctico 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 sacarina sintáctica y jarabe sintáctico , es decir, sintaxis gratuita que no facilita la programación. [17] [18] [19] [20]
Se dice que los tipos de datos con soporte sintáctico central son "tipos azucarados". [21] [22] [23] Los ejemplos comunes incluyen cadenas delimitadas por comillas, llaves para tipos de objetos y registros, y corchetes para matrices.
Sin embargo, la expresión de asignación compuesta no es equivalente a la versión expandida porque la expresión de asignación compuesta evalúa la expresión1 solo una vez, mientras que la versión expandida evalúa la expresión1 dos veces: en la operación de suma y en la operación de asignación.
la optimización se puede [realizar] si 'encontrar x' no tiene efectos secundarios
{{cite journal}}: Citar diario requiere |journal=( ayuda )