¿Definición rigurosa de azúcar sintáctico? [cerrado]

Parece que en el lenguaje de las guerras santas, las personas constantemente denigran cualquier característica que no encuentran particularmente útil como "azúcar sintáctico". La línea entre "características reales" y "azúcar sintáctico" tiende a desdibujarse en estos debates. ¿Cuál cree que es una definición razonable e inequívoca de azúcar sintáctico que evita que se defina como una característica que el hablante / escritor no encuentra útil?

Qué tal esto: "el azúcar sintáctico es una abreviatura conveniente para algunas funciones que no introducen ninguna capa significativa de abstracción".

Tome a->b, que, como señala, es equivalente a (*a).b. ¿Esta notación le permite considerar el código de alguna manera útil, de otra manera oculta? No, entonces es azúcar sintáctico.

Ahora considera a[i] == *(a + i). Piense en cualquier programa de C que use matrices de cualquier forma sustantiva. ¿Te imaginas tratar de comprenderlo sin la []notación? Con matrices multidimensionales? Es significativo considerar las matrices como unidades completas, no como una referencia al comienzo de un bloque contiguo de memoria. Si bien es útil saber cómo funcionan las matrices en C si está planeando hacer cosas complicadas con ellas, no es productivo tener que pensar siempre "Necesito almacenar los dos bits de memoria 2 * i bytes a la derecha del ubicación de memoria referenciada por a". El objetivo de una matriz es la capacidad de abstraer el proceso de almacenamiento de una secuencia como una unidad coherente. La []notación facilita esta abstracción. Es sin azúcar sintáctico.

Esto no implica que el azúcar sintáctico sea siempre algo malo. Como muchas aliteraciones, se ha convertido en un epíteto y se enfrenta a las "características reales". Pero LISP y Scheme, por ejemplo, serían ilegibles si no fuera por la lettaquigrafía (y otros).

El operador ternario,, <pred> ? <cnsq> : <alt>es otro ejemplo. El azúcar sintáctico puede ayudar a organizar programas y eliminar código redundante, lo que puede ahorrar en el mantenimiento en el futuro. El azúcar sintáctico a veces puede ser preferible a acumular "características reales" si ayuda a eliminar las barreras sintácticas para la programación.

Para citar R ^ 5RS , "Los lenguajes de programación deben diseñarse no acumulando la función encima de la función, sino eliminando las debilidades y restricciones que hacen que las funciones adicionales parezcan necesarias". En mi humilde opinión, la sintaxis puede calificar como una debilidad y restricción, por lo que permitir que los programadores se alejen de la sintaxis puede aumentar la expresividad de un lenguaje.

En mi humilde opinión, no creo que pueda tener una definición para el azúcar sintáctico, porque la frase es BS y es probable que sea utilizada por personas que hablan de "programadores reales" que usan "herramientas reales" en "sistemas operativos reales".

Su BS porque la idea de "características reales" o "azúcar sintáctico" es como la falacia No verdadero escocés . En ese sentido, las frases son "intentos ad hoc para retener una afirmación irracional". La afirmación aquí es que una característica aquí es trivial porque podría usar una "característica real" en su lugar.

Es BS porque algunos argumentan que se debe evitar el uso de azúcar porque puede escribir un error, pero debe atenerse a él porque es más difícil de escribir errores. ¿No es asombroso? La misma frase lleva a conclusiones exactamente opuestas usando la misma lógica.

Su BS porque nadie cita estudios de usabilidad o estudios de conteo de defectos, para respaldar su legibilidad o mantenibilidad o posibles argumentos de defectos.

Es BS porque las personas a menudo están equivocadas o se equivocan acerca de la equivalencia. Por ejemplo, esta pregunta afirma que una cadena de C # es azúcar para una matriz de caracteres. No son .

Sin embargo, si quiere decir que dos cosas son azúcar si son semánticamente equivalentes y eso ayuda a seguir adelante y definirlo de la forma que desee.

Si quieres despreciar a alguien, también puedes usar la frase.

Aquí hay una definición muy rigurosa para un concepto relacionado: expresividad , por
Matthias Felleisen:

Sobre el poder expresivo de los lenguajes de programación [Postscript fue la única forma gratuita que pude encontrar]

Consulte también esta entrada sobre el lenguaje Java y los cierres .

Efectivamente, algo es azúcar sintáctico si se puede cambiar a una forma sin la sintaxis solo haciendo cambios locales. Si, por ejemplo, sin la forma sintáctica, necesita cambiar varias ubicaciones de código diferentes o mover fragmentos a otras ubicaciones, entonces no es azúcar.

Dicho esto, el azúcar sintáctico está bien cuando se usa adecuadamente. Creo que cualquier programador de Scheme preferiría que hubiera una letforma especial que tener que crear una nueva función anónima y luego aplicarla, lo que haría lo mismo. El propósito es aclarar el código.

Creo que el término azúcar sintáctico indica una sintaxis alternativa para expresar la misma semántica subyacente.

Tomemos, por ejemplo, un lenguaje de programación A que tiene una operación sumque puede sumar una lista de enteros de longitud arbitraria. En este lenguaje podemos escribir las expresiones

sum []
sum [3, 4, 5, 1]
sum [2, 7]

cuyos resultados son 0, 13 y 9, respectivamente.

Ahora, supongamos que nos damos cuenta de que el 90% de las veces lo usamos sumcon dos argumentos y, por lo tanto, presentamos, por conveniencia, la nueva notación

2 + 7

que es sólo azúcar sintáctico para sum [2, 7].

Ahora tome un segundo idioma B que no tenga ninguna operación de suma. Es posible que tengamos operadores como <, =lo que nos permite comparar números, pero no hay forma de agregar números. En la versión 2 del lenguaje B, presentamos una nueva operación de adición con sintaxis

2 + 7

que agrega números como de costumbre.

En el contexto del lenguaje A, la +notación es azúcar sintáctica (es una notación alternativa, simplificada y ad-hoc que se puede usar en lugar de la sum [...]notación). De manera similar, como se ha señalado en la respuesta de Hoa Long Tam, en C la notación p->fieldes azúcar sintáctica para (*p).field.

En el contexto del lenguaje B, la +notación no es azúcar sintáctica (es la única sintaxis válida utilizada para la operación de suma). De manera similar, si C solo pudiera acceder a los miembros de la estructura a través de punteros y si no tuviera la notación (*p).field, entonces la notación p->fieldno sería azúcar sintáctica.

En mi opinión, hay algunos malentendidos sobre el azúcar sintáctico que se remontan a una confusión con respecto a la semántica del lenguaje de programación. El razonamiento es así:

• La semántica de un programa es lo que un programa calcula.
• El poder expresivo de un lenguaje de programación está representado por los cálculos que se pueden describir en ese lenguaje.
• Dos lenguajes de programación que pueden describir todas las funciones computables (como se define usando las máquinas de Turing) tienen el mismo poder expresivo ...
• ... y, por lo tanto, solo difieren en la sintaxis.
• Corolario: cualquier extensión de un lenguaje completo de Turing es solo sintaxis (azúcar sintáctico) porque no cambia el poder expresivo del lenguaje.

La línea de razonamiento anterior conduce a afirmaciones genéricas como "el azúcar sintáctico no se puede definir correctamente", es una "cuestión de gustos" o "después de todo, cada característica del lenguaje de programación es solo azúcar sintáctico".

Creo que el principal problema en el argumento anterior es que la semántica no solo se trata de lo que un programa puede calcular , sino también de cómo se calcula , es decir, qué construcciones primitivas se usan y cómo se combinan.

Entonces, por ejemplo, los objetos no son azúcar sintáctica para las configuraciones de bits subyacentes y las transformaciones de bits, son una construcción que permite modelar datos y operaciones y describir cálculos. Calcular con objetos, métodos, llamadas a métodos no es lo mismo que calcular con bytes, registros de procesador, direcciones de memoria (incluso si los dos cálculos tienen el mismo resultado, e incluso si el segundo cálculo se usa para implementar el primero).

Hice esta descripción un poco larga, pero creo que es un aspecto importante que no he visto en otras respuestas.

En pocas palabras: el azúcar sintáctico es una sintaxis alternativa (posiblemente más conveniente) para una construcción que ya está en un lenguaje y que ya tiene una sintaxis y una semántica bien definidas. La nueva sintaxis (azúcar sintáctica) difiere de la existente, pero tiene la misma semántica . Si introduce una nueva construcción en un lenguaje y una nueva sintaxis para él, entonces no tiene azúcar sintáctico.

El azúcar sintáctico es una característica que no extiende la expresividad del lenguaje en sí misma, por lo tanto, es redundante y, a veces, un abuso de notación, pero que simplifica la vida del escritor y le da al lector más información.

Para responder a mi propia pregunta, una característica es el azúcar sintáctico si y solo si se incluyó principalmente para mejorar la estética y la legibilidad y puede traducirse trivialmente de una manera más o menos individual en la versión no azucarada. (Por más o menos uno a uno me refiero a cosas modulares triviales como el orden de operaciones conmutativas, nombres de variables y espacios en blanco).

Cualquier característica que solo se pueda eliminar con una cantidad significativa de disciplina del programador no es azúcar sintáctica. Como subconjunto de esto, cualquier característica que aumente la seguridad del tipo no es azúcar sintáctica, ya que hacer cumplir manualmente la seguridad del tipo a través de la disciplina del programador es altamente no trivial. Por ejemplo, el sistema de objetos de C ++ es más que un azúcar sintáctico además del polimorfismo de fundición de puntero en C.

Cualquier característica que requiera una duplicación significativa del código o un rediseño importante si se elimina no es azúcar sintáctica, ya que ninguna de estas es una tarea trivial. Por ejemplo, las plantillas no son solo azúcar sintáctica porque obtener la funcionalidad equivalente sin ellas requeriría toneladas de clonar y modificar.

Ejemplo de cosas que son azúcar sintáctica:

a[i] en vez de *(a + i)

a -> b en vez de (*a).b

foreach sintaxis en lugar de escribir manualmente la sintaxis del iterador.

Toda sobrecarga del operador es azúcar sintáctica pura.

¿Suena esto como una definición justa y razonablemente inequívoca?

"Azúcar sintáctico" no es un término rigurosamente definido. Dependiendo de a quién le pregunte, lo más probable es que obtenga uno de los siguientes tipos de definiciones:

1. No hay un verdadero enfoque escocés. Las cosas que me gustan son programación real, y las cosas que no me gustan son el azúcar sintáctico.
2. Todo después de MIPS fue azúcar sintáctico, e incluso algunas de esas instrucciones probablemente no sean necesarias.
3. Cualquier cosa que facilite la programación para alguien en algún lugar es útil y no un azúcar sintáctico. Dado que una característica no se habría agregado si nadie la encontrara útil en ninguna circunstancia, se deduce que cada característica existente no es azúcar sintáctica. Las características hipotéticas pueden ser azúcar sintáctica, hasta que alguien decida que esa característica les es útil.

No estoy seguro acerca de los campos de las ciencias de la computación, pero con el campo de la lógica existen los conceptos de conservadurismo y eliminación de definiciones [ 1 ] que parecen estar en la misma línea.

Aplicando la correspondencia Curry-Howard, se podría llegar a un concepto paralelo con respecto al "azúcar sintáctico".