Definizione rigorosa dello zucchero sintattico? [chiuso]

Che ne dici di questo: "lo zucchero sintattico è una comoda scorciatoia per alcune funzionalità che non introducono alcun livello significativo di astrazione."

Prendi a->b , che, come fai notare, equivale a (*a).b . Questa notazione ti consente di considerare il codice in qualsiasi modo utile, altrimenti nascosto? No, quindi è zucchero sintattico.

Ora considera a[i] == *(a + i) . Pensa a qualsiasi programma C che usi gli array in modo sostanziale. Riesci a immaginare di provare a comprenderlo senza la notazione [] ? Con array multidimensionali? È significativo considerare gli array come unità intere, non come riferimento all'inizio di un blocco contiguo di memoria. Mentre aiuta a sapere come funzionano gli array in C se stai pensando di fare cose complicate con loro, è improduttivo dover pensare sempre "Ho bisogno di memorizzare i due bit di memoria 2 * i byte a destra del posizione di memoria a cui fa riferimento a . " L'intero punto di un array è la capacità di astrarre il processo di memorizzazione di una sequenza come unità coerente. La notazione [] facilita questa astrazione. È non zucchero sintattico.

Questo non significa che lo zucchero sintattico sia sempre una cosa negativa. Come molte allitterazioni, è diventato un epiteto e messo a confronto con le "caratteristiche reali". Ma LISP e Scheme, per esempio, sarebbero illeggibili se non fossero per la% st_de% stenografia (e altri).

L'operatore ternario, let , è un altro esempio. Lo zucchero sintattico può aiutare a organizzare i programmi e rimuovere il codice ridondante, che può salvare la manutenzione in linea. Lo zucchero sintattico a volte può essere preferibile ad accumulare su "caratteristiche reali" se aiuta a rimuovere le barriere sintattiche alla programmazione.

Per citare R ^ 5RS , "I linguaggi di programmazione dovrebbero essere progettato non dalla funzione di impilamento sulla parte superiore della funzionalità, ma rimuovendo i punti deboli e le restrizioni che rendono necessarie funzionalità aggiuntive. " IMHO, la sintassi può essere considerata una debolezza e una limitazione e quindi lasciare che i programmatori si allontanino dalla sintassi può aumentare l'espressività di una lingua.

IMHO Non penso che tu possa avere una definizione per lo zucchero sintattico, perché la frase è BS ed è probabile che sia usata da persone che parlano di "veri programmatori" usando "strumenti reali" su "sistemi operativi reali"

La sua BS perché l'idea di "caratteristiche reali" o "zucchero sintattico" è come Nessuna vera falsità da Scotsman . In quanto le frasi sono "tentativi ad hoc di mantenere un'asserzione irragionevole". L'asserzione qui è che una caratteristica qui è banale perché si potrebbe usare invece una "funzione reale".

Il BS perché alcuni sostengono che l'uso dello zucchero dovrebbe essere evitato perché puoi scrivere un bug ma tu dovrebbe attenersi ad esso perché è più difficile scrivere bug. Non è fantastico? La stessa frase porta a conclusioni esattamente opposte usando la stessa logica.

La sua BS perché nessuno cita studi di usabilità o studi di conteggio dei difetti, per verificarne la leggibilità o la manutenibilità o gli argomenti probabili relativi ai difetti.

È BS perché le persone sbagliano spesso o si sbagliano riguardo all'equivalenza. Ad esempio questa domanda afferma che una stringa C # è zucchero per un array di caratteri. Non sono .

Tuttavia, se vuoi dire che due cose sono zucchero se sono semanticamente equivalenti e questo aiuta a procedere e definirlo in ogni caso.

Se vuoi essere sprezzante con qualcuno puoi anche usare la frase.

Ecco una definizione rigorosa molto per un concetto correlato: espressività , di
Matthias Felleisen:

On the Expressive Power of Programming Languages [Postscript was the only free form I could find.]

Vedi anche questa voce su linguaggio Java e chiusure .

In effetti, qualcosa è zucchero sintattico se può essere modificato in una forma senza la sintassi, apportando solo modifiche locali. Se, ad esempio, senza la forma sintattica, avresti bisogno di cambiare diverse posizioni di codice o spostare frammenti in altre posizioni, quindi non è zucchero.

Detto questo, lo zucchero sintattico va bene se usato in modo appropriato. Penso che ogni programmatore di Scheme preferirebbe che ci fosse una forma speciale let piuttosto che dover creare una nuova funzione anonima e quindi applicarla, il che farebbe la stessa cosa. Lo scopo è rendere il codice più chiaro.

Penso che il termine zucchero sintattico indichi una sintassi alternativa per esprimere la stessa semantica sottostante.

Prendiamo ad esempio un linguaggio di programmazione A che ha un'operazione sum che può sommare una lista di numeri interi di lunghezza arbitraria. In questa lingua possiamo scrivere le espressioni

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

i cui risultati sono 0, 13 e 9, rispettivamente.

Ora, supponiamo che realizziamo che il 90% delle volte usiamo sum con due argomenti, e quindi introduciamo, per comodità, la nuova notazione

2 + 7

che è solo zucchero sintattico per sum [2, 7] .

Ora prendi una seconda lingua B che abbia l'operazione di aggiunta no di sorta. Potremmo avere operatori come < , = , che ci consente di confrontare i numeri, ma non c'è modo di aggiungere numeri. Nella versione 2 della lingua B, introduciamo una nuova operazione aggiunta con sintassi

2 + 7

che aggiunge i numeri come al solito.

Nel contesto del linguaggio A, la notazione + è zucchero sintattico (è una notazione alternativa, semplificata e ad-hoc che può essere utilizzata al posto della notazione sum [...] ). Allo stesso modo, come è stato sottolineato nella risposta di Hoa Long Tam, in C la notazione p->field è zucchero sintattico per (*p).field .

Nel contesto del linguaggio B, la notazione + è non zucchero sintattico (è l'unica sintassi valida utilizzata per l'operazione somma). Allo stesso modo, se C potesse accedere solo ai membri della struct attraverso i puntatori e se non avesse la notazione (*p).field , la notazione p->field non sarebbe zucchero sintattico.

Secondo me, ci sono alcuni equivoci sullo zucchero sintattico che possono essere ricondotti a una confusione riguardante la semantica del linguaggio di programmazione. Il ragionamento va così:

• La semantica di un programma è ciò che un programma calcola.
• Il potere espressivo di un linguaggio di programmazione è rappresentato dai calcoli che possono essere descritti in quella lingua.
• Due linguaggi di programmazione in grado di descrivere tutte le funzioni computabili (come definite utilizzando le macchine di Turing) hanno la stessa potenza espressiva ...
• ... e quindi differiscono solo per la sintassi.
• Corollario: qualsiasi estensione di una lingua completa di Turing è solo sintassi (zucchero sintattico) perché non si modifica la potenza espressiva della lingua.

La suddetta linea di ragionamento porta a affermazioni generiche come "lo zucchero sintattico non può essere definito correttamente", è una "questione di gusto", o "ogni caratteristica del linguaggio di programmazione è, dopo tutto, solo zucchero sintattico".

Penso che il problema principale nell'argomento sopra sia che la semantica non riguarda solo ciò che può essere calcolato da un programma, ma anche come è calcolato , cioè quali costrutti primitivi sono usati e come sono combinati.

Quindi, ad esempio, oggetti non sono zucchero sintattico per le configurazioni di bit e trasformazioni di bit sottostanti, sono un costrutto che consente di modellare dati e operazioni e di descrivere calcoli. Il calcolo con oggetti, metodi, chiamate di metodo, non equivale al calcolo con byte, registri del processore, indirizzi di memoria (anche se i due calcoli hanno lo stesso risultato e anche se il secondo calcolo viene utilizzato per implementare il primo).

Ho reso questa descrizione un po 'lunga, ma penso che sia un aspetto importante che non ho visto indirizzato in altre risposte.

Bottom line: lo zucchero sintattico è una sintassi alternativa (possibilmente più conveniente) per un costrutto che è già in una lingua e ha già una sintassi e una semantica ben definite. La nuova sintassi (zucchero sintattico) differisce da quella esistente ma ha la stessa semantica . Se si introduce un nuovo costrutto in una lingua e una nuova sintassi per esso, allora non si dispone di zucchero sintattico.

lo zucchero sintattico è una caratteristica che non estende l'espressività linguistica stessa, quindi è ridondante e talvolta un abuso di notazione, ma entrambi semplificano la vita dello scrittore e danno al lettore più informazioni.

Per rispondere alla mia domanda, una funzione è zucchero sintattico se e solo se è stata inclusa principalmente per migliorare l'estetica e la leggibilità e può essere banalmente tradotta in modo approssimativamente one-to-one in la versione de-zuccherata. (Intendendo approssimativamente uno-a-uno intendo le cose banali come l'ordine delle operazioni commutative, i nomi delle variabili e gli spazi bianchi.)

Qualsiasi caratteristica che potrebbe essere solo de-zuccherata con una quantità significativa di disciplina da programmatore non è zucchero sintattico. Come un sottoinsieme di ciò, qualsiasi funzionalità che aumenta la sicurezza del tipo non è zucchero sintattico, poiché applicare manualmente la sicurezza del tipo tramite la disciplina del programmatore è altamente non banale. Ad esempio, il sistema di oggetti di C ++ è più che zucchero sintattico in cima al polimorfismo del cast di puntatore a C.

Qualsiasi funzionalità che richiederebbe una significativa duplicazione del codice o una riprogettazione importante se rimosso non è zucchero sintattico, poiché nessuna di queste è un'impresa banale. Ad esempio, i modelli non sono solo zucchero sintattico perché ottenere la funzionalità equivalente senza di essi richiederebbe tonnellate di clonazione e modifica.

Esempio di cose che sono zucchero sintattico:

a[i] anziché *(a + i)

a -> b anziché (*a).b

foreach syntax invece di digitare manualmente la sintassi iteratore.

Tutto l'overloading dell'operatore è puro zucchero sintattico.

Questo suona come una definizione equa e ragionevolmente non ambigua?

Lo "zucchero sintattico" non è un termine rigorosamente definito. A seconda di chi chiedi, molto probabilmente otterrai uno dei seguenti tipi di definizioni:

1. Nessun vero approccio da scozzese. Le cose che mi piacciono sono la vera programmazione, e le cose che non mi piacciono sono lo zucchero sintattico.
2. Tutto dopo MIPS era zucchero sintattico, e anche alcune di quelle istruzioni probabilmente non sono necessarie.
3. Tutto ciò che rende la programmazione più facile per qualcuno da qualche parte è utile e non sintattica. Poiché una funzione non sarebbe stata aggiunta se nessuno l'avesse trovata utile in nessuna circostanza, ne consegue che ogni caratteristica esistente non è zucchero sintattico. Le caratteristiche ipotetiche possono essere lo zucchero sintattico, fino a quando qualcuno decide che tale funzione è utile per loro.

Non sono sicuro riguardo ai campi delle scienze informatiche, ma con il campo della logica ci sono i concetti di conservatorività ed eliminabilità delle definizioni [ 1 ] sembra essere nella stessa vena.

Applicando la corrispondenza Curry-Howard, si potrebbe essere in grado di elaborare un concetto parallelo relativo allo "zucchero sintattico".