it-swarm-es.com

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

Parece que en las guerras santas del lenguaje, la gente denigra constantemente cualquier característica que no encuentran particularmente útil como si fuera "simplemente 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áctica que evita que se defina como cualquier característica que el hablante/escritor no encuentre útil?

9
dsimcha

Qué tal esto: "el azúcar sintáctico es una abreviatura de conveniencia para alguna funcionalidad que no introduce ninguna capa significativa de abstracción".

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

Ahora considere a[i] == *(a + i). Piense en cualquier programa en C que utilice matrices de forma sustancial. ¿Te imaginas intentar comprenderlo sin la notación []? ¿Con matrices multidimensionales? Es significativo considerar las matrices como unidades completas, no como una referencia al inicio de un bloque de memoria contiguo. Si bien es útil saber cómo funcionan las matrices en C si está planeando hacer cosas complicadas con ellas, es improductivo tener que pensar siempre "Necesito almacenar los dos bits de memoria 2 * i bytes a la derecha de la ubicación de memoria referenciada por a. " El objetivo de una matriz es la capacidad de abstraer el proceso de almacenar una secuencia como una unidad coherente. La notación [] Facilita esta abstracción. Es no 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 ha enfrentado a "características reales". Pero LISP y Scheme, por ejemplo, serían ilegibles si no fuera por la abreviatura let (y otras).

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 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 a la programación.

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

19
Hoa Long Tam

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

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

También vea esta entrada en el Java lenguaje y cierres .

Efectivamente, algo es azúcar sintáctico si se puede cambiar a una forma sin la sintaxis haciendo solo 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 apropiadamente. Creo que cualquier programador de Scheme preferiría que hubiera una forma especial let que tener que crear una nueva función anónima y luego aplicarla, lo que haría lo mismo. El propósito es hacer que el código sea más claro.

7
Macneil

En mi humilde opinión, no creo que puedas tener una definición de azúcar sintáctico, porque la frase es BS y es probable que la utilicen personas que hablan de "programadores reales" que utilizan "herramientas reales" en "sistemas operativos reales".

Es una tontería porque la idea de "características reales" o "azúcar sintáctica" es como la No hay verdadera falacia escocesa . En que las frases son "intentos ad hoc de retener una afirmación sin fundamento". La afirmación aquí es que una característica aquí es trivial porque podría usar una "característica real" en su lugar.

Es una tontería porque algunos argumentan que el uso de azúcar debería ser evitado porque puede escribir un error, pero usted debería atenerse a él porque es más difícil escribir errores. ¿No es maravilloso? La misma frase lleva a conclusiones exactamente opuestas utilizando la misma lógica.

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

Es una tontería porque la gente a menudo se equivoca o se equivoca acerca de la equivalencia. Por ejemplo esta pregunta afirma que una cadena C # es azúcar para una matriz de caracteres. No lo son .

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

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

7
Conrad Frix

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 sum que puede sumar una lista de números enteros de longitud arbitraria. En este idioma podemos escribir las expresiones

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

cuyos resultados son 0, 13 y 9, respectivamente.

Ahora, suponga que nos damos cuenta de que el 90% de las veces usamos sum con dos argumentos, y por lo tanto introducimos, por conveniencia, la nueva notación

2 + 7

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

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

2 + 7

que agrega números como de costumbre.

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

En el contexto del lenguaje B, el + notación es no 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, luego la notación p->field no sería azúcar sintáctico.

En mi opinión, existen 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 el siguiente:

  • La semántica de un programa es lo que calcula un programa.
  • 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 definen usando máquinas de Turing) tienen el mismo poder expresivo ...
  • ... y por lo tanto solo difieren en sintaxis.
  • Corolario: cualquier extensión de un lenguaje Turing-completo 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 gusto", o "cada característica del lenguaje de programación es, después de todo, sólo azúcar sintáctico".

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

Entonces, por ejemplo, objetos no son azúcar sintáctico 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 abordado 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 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 ella, entonces no tiene azúcar sintáctico.

3
Giorgio

"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 la 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 es 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 todas las características existentes no son azúcar sintáctico. Las características hipotéticas pueden ser azúcar sintáctico, hasta que alguien decide que esa característica le es útil.
0
Patrick87

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

0
Lorenzo Stella

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

Cualquier característica que solo pueda eliminarse con una cantidad significativa de disciplina de programador no es azúcar sintáctica. Como un subconjunto de esto, cualquier característica que aumente la seguridad de tipos no es azúcar sintáctico, ya que la aplicación manual de la seguridad de tipos a través de la disciplina del programador no es nada trivial. Por ejemplo, el sistema de objetos de C++ es más que azúcar sintáctico además del polimorfismo de conversión de puntero de 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 empresa trivial. Por ejemplo, las plantillas no son solo azúcar sintáctico porque obtener la funcionalidad equivalente sin ellas requeriría toneladas de clonar y modificar.

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

a[i] En lugar de *(a + i)

a -> b En lugar de (*a).b

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

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

¿Suena esto como una definición justa y razonablemente ambigua?

0
dsimcha