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 se pueden expresar de manera más clara, más concisa o en un estilo alternativo que algunos pueden preferir. El azúcar sintáctico suele ser una abreviatura para una operación común que también podría expresarse en una forma alternativa, más detallada: el programador tiene la opción de usar la forma más corta o la forma más larga, pero generalmente usará la forma más corta, ya que es más corta 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 una matrizget_array(Array, vector(i,j))
. 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 . En cambio, muchos lenguajes proporcionan una sintaxis como Array[i,j]
. De manera similar, una actualización de un elemento de una 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
.
Un constructo en un lenguaje es azúcar sintáctico si puede eliminarse del lenguaje sin ningún efecto sobre lo que el lenguaje puede hacer: 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 endulzadas en sus equivalentes más detallados antes de procesarlas, 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 de superficie 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 "donde".
Lenguajes de programación posteriores, como CLU , ML y Scheme , extendieron el término para referirse a la sintaxis dentro de un lenguaje que podía definirse en términos de un núcleo de lenguaje de construcciones esenciales; las características convenientes de nivel superior podían "desazucar" y descomponerse en ese subconjunto. [3] Esta es, de hecho, la práctica matemática habitual de construir a partir de primitivos.
Partiendo de 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 "creencias ampliamente aceptadas" en la literatura. Definió "más expresivo" como que sin las construcciones lingüísticas en cuestión, un programa tendría que ser reorganizado por completo. [4]
MOVE A B.
y la oración MOVE A TO B.
realizan exactamente la misma función, pero la segunda hace que la acción que se debe realizar sea más clara.a += b
es equivalente a a = a + b
en C y lenguajes similares, asumiendo que a
no tiene efectos secundarios como si a
es 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 una sintaxis simplificada para if (not condition) {...}
. Además, cualquier declaración puede ir seguida de una condición, por lo que statement if condition
es equivalente a if (condition) {statement}
, pero la primera tiene un formato más natural en una sola línea.a[i]
notación es un azúcar sintáctico para *(a + i)
. [8] Asimismo, la a->x
notación es un azúcar sintáctico para acceder a miembros utilizando el operador de desreferencia (*a).x
.using
declaració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 x
a partir de la expresión expr
, en lugar de requerir una declaración de tipo explícita. De manera similar, C++ lo permite auto x = expr
desde C++11 y Java lo permite var x = expr
desde Java 11.[x*x for x in range(10)]
para una lista de cuadrados) y decoradores (como @staticmethod
).%>%
, declara que los datos (o 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] Por lo tanto, x %>% f(y)
es equivalente a f(x,y)
.JOIN
es equivalente a un an INNER JOIN
, lo que aclara que la instrucción join es específicamente una operación de unión interna en lugar de una operación de unión externa. Asimismo, se puede omitir el OUTER
de LEFT OUTER JOIN
, RIGHT OUTER JOIN
y FULL OUTER JOIN
.myObject.myMethod(parameter1, parameter2, parameter3)
es una sintaxis simplificada para llamar a una función global como . La referencia al objeto se pasa como un argumento oculto, normalmente accesible desde dentro del método como .myMethod(myObject, parameter1, parameter2, parameter3)
this
import
declaració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 por ejemplo, javax.swing.JButton
utilizando el nombre más corto JButton
.(x) => x + 1
, que es equivalente a la forma más larga (x) => { return x + 1; }
. ???
) son equivalentes a throw new NotImplementedError
. Esto es útil para marcar un lugar para el código que aún no se ha escrito. [11]Algunos programadores creen que estas características de usabilidad de la sintaxis son poco importantes o directamente 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 opinió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 " Epigrams on Programming ", en una referencia a los lenguajes delimitados por corchetes , que "el azúcar sintáctico causa cáncer de los puntos y coma ". [13]
La metáfora se ha ampliado con 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 superar solo para demostrar que saben lo que está sucediendo, en lugar de expresar una acción del programa.
En C# , al ocultar un miembro de una clase heredada, se emite una advertencia del compilador a menos que new
se 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 switch con la de C o C++, C# requiere una break
para cada etiqueta no vacía case
de a switch
(a menos que se use goto
, return
o throw
) aunque no permite un paso a través implícito . [16] (El uso y la especificación de la etiqueta posterior produce un paso a travésgoto
similar a C/C++ ).
La sal sintáctica puede anular 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 hay una alta probabilidad de que el código sea el resultado de un error, una práctica común en los compiladores C/C++ modernos.
Otras extensiones son la sacarina sintáctica y el jarabe sintáctico , es decir, una sintaxis gratuita que no facilita la programación. [17] [18] [19] [20]
Se dice que los tipos de datos con soporte sintáctico básico 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 expresión1 solo una vez, mientras que la versión expandida evalúa expresión1 dos veces: en la operación de suma y en la operación de asignación.
La optimización se puede hacer si "encontrar x" no tiene efectos secundarios.
{{cite journal}}
: Requiere citar revista |journal=
( ayuda )