Sembra che nelle guerre sante del linguaggio le persone denigrino costantemente qualsiasi caratteristica che non trovano particolarmente utile come "solo zucchero sintattico". La linea di demarcazione tra "caratteristiche reali" e "zucchero sintattico" tende a confondersi in questi dibattiti. Cosa ritieni sia una definizione ragionevole e inequivocabile di zucchero sintattico che evita che venga definita come qualsiasi caratteristica che l'oratore / scrittore non trova utile?
Risposte:
Che ne dici di questo: "lo zucchero sintattico è una scorciatoia per alcune funzionalità che non introduce 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 qualche modo utile, altrimenti nascosto? No, quindi è zucchero sintattico.
Adesso considera a[i] == *(a + i). Pensa a qualsiasi programma C che utilizza array in modo sostanziale. Riesci a immaginare di provare a comprenderlo senza la []notazione? Con array multidimensionali? È significativo considerare le matrici come unità intere, non come riferimento all'inizio di un blocco contiguo di memoria. Mentre aiuta a sapere come funzionano le matrici in C se stai pianificando di fare cose complicate con loro, non è produttivo 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 sottrarre il processo di memorizzazione di una sequenza come unità coerente. La []notazione facilita questa astrazione. E ' non è zucchero sintattico.
Questo non implica che lo zucchero sintattico sia sempre una brutta cosa. Come molte allitterazioni, è diventato un epiteto e contrapposto a "caratteristiche reali". Ma LISP e Scheme, per esempio, sarebbero illeggibili se non per la letstenografia (e altri).
L'operatore ternario <pred> ? <cnsq> : <alt>, è un altro esempio. Lo zucchero sintattico può aiutare a organizzare i programmi e rimuovere il codice ridondante, che può risparmiare nella manutenzione lungo la linea. Lo zucchero sintattico può talvolta essere preferibile ad accumulare "caratteristiche reali" se aiuta a rimuovere le barriere sintattiche alla programmazione.
Per citare R ^ 5RS , "I linguaggi di programmazione dovrebbero essere progettati non accatastando la funzionalità sopra la funzionalità, ma rimuovendo i punti deboli e le restrizioni che rendono necessarie funzionalità aggiuntive". IMHO, la sintassi può qualificarsi come debolezza e restrizione 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 di zucchero sintattico, perché la frase è BS ed è probabile che venga usata da persone che parlano di "programmatori reali" usando "strumenti reali" su "sistemi operativi reali"
È BS perché l'idea di "caratteristiche reali" o "zucchero sintattico" è come il vero errore di No Scotsman . In quanto le frasi sono "tentativi ad hoc di mantenere un'asserzione irragionevole". L'affermazione qui è che una caratteristica qui è banale perché potresti usare una "caratteristica reale" invece.
È BS perché alcuni sostengono che l'uso dello zucchero dovrebbe essere evitato perché è possibile scrivere un bug ma è necessario attenersi ad esso perché è più difficile scrivere bug. Non è fantastico. La stessa frase porta a conclusioni esattamente opposte usando la stessa logica.
È BS perché nessuno cita studi di usabilità o studi sul conteggio dei difetti, per sostenere la loro leggibilità o manutenibilità o probabili argomenti di difetto.
È BS perché le persone spesso sbagliano o si sbagliano sull'equivalenza. Ad esempio, questa domanda afferma che una stringa C # è zucchero per un array di caratteri. Non lo sono .
Tuttavia, se vuoi dire che due cose sono zucchero se sono semanticamente equivalenti e questo aiuta ad andare avanti e a definirlo come preferisci.
Se vuoi essere sprezzante nei confronti di qualcuno, puoi anche usare la frase.
Ecco una definizione molto rigorosa per un concetto correlato: espressività , di
Matthias Felleisen:
Sulla potenza espressiva dei linguaggi di programmazione [Postscript era l'unica forma libera che potessi trovare.]
Vedi anche questa voce sul linguaggio Java e le chiusure .
In effetti, qualcosa è zucchero sintattico se può essere modificato in un modulo senza la sintassi apportando solo modifiche locali. Se, ad esempio, senza il modulo sintattico, dovessi cambiare diverse posizioni di codice o spostare frammenti in altre posizioni, allora non è zucchero.
Detto questo, lo zucchero sintattico va bene se usato in modo appropriato. Penso che qualsiasi programmatore di Scheme preferirebbe che ci fosse una letforma speciale piuttosto che dover creare una nuova funzione anonima e quindi applicarla, 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 sumche può sommare un elenco 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.
Supponiamo ora di renderci conto che il 90% delle volte che usiamo sumcon 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 non ha alcuna operazione di aggiunta. Potremmo avere operatori come <, =che ci permettono di confrontare i numeri, ma non c'è modo di aggiungere numeri. Nella versione 2 del linguaggio B, introduciamo una nuova operazione di aggiunta con la sintassi
2 + 7
che aggiunge 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 sum [...]notazione). 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 di somma). Allo stesso modo, se C potesse accedere ai membri di struct solo tramite puntatori e se non avesse la notazione (*p).field, allora la notazione p->fieldnon sarebbe zucchero sintattico.
A mio avviso, ci sono alcuni malintesi sullo zucchero sintattico che possono essere ricondotti a una confusione riguardo alla semantica del linguaggio di programmazione. Il ragionamento va così:
La suddetta linea di ragionamento porta a affermazioni generiche come "lo zucchero sintattico non può essere definito correttamente", è una "questione di gusti" o "ogni caratteristica del linguaggio di programmazione è, dopotutto, solo zucchero sintattico".
Penso che il problema principale nell'argomento precedente sia che la semantica non riguarda solo ciò che può essere calcolato da un programma, ma anche il modo in cui viene calcolato , ovvero quali costrutti primitivi vengono utilizzati e come vengono combinati.
Quindi, ad esempio, gli oggetti non sono zucchero sintattico per le configurazioni 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 è uguale 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 affrontato in altre risposte.
In conclusione: lo zucchero sintattico è una sintassi alternativa (forse 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, non si ha zucchero sintattico.
lo zucchero sintattico è una caratteristica che non estende l'espressività del linguaggio stesso, quindi è ridondante e talvolta un abuso della notazione, ma ciò semplifica la vita dello scrittore e fornisce al lettore maggiori informazioni.
Per rispondere alla mia domanda, una caratteristica è lo zucchero sintattico se e solo se è stato incluso principalmente per migliorare l'estetica e la leggibilità e può essere banalmente tradotto in una versione prettamente individuale nella versione priva di zucchero. (Per circa uno a uno intendo cose banali modulo come l'ordine delle operazioni commutative, i nomi delle variabili e gli spazi bianchi.)
Qualsiasi caratteristica che potrebbe essere eliminata con una notevole quantità di disciplina da programmatore non è zucchero sintattico. Come sottoinsieme di ciò, qualsiasi caratteristica che aumenta la sicurezza del tipo non è zucchero sintattico, poiché applicare manualmente la sicurezza del tipo tramite la disciplina del programmatore è estremamente banale. Ad esempio, il sistema a oggetti di C ++ è più che uno zucchero sintattico in cima al polimorfismo del cast di puntatori C.
Qualsiasi caratteristica che richiederebbe una duplicazione significativa del codice o una riprogettazione importante se rimossa 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 clone-e-modifica.
Esempio di cose che sono zucchero sintattico:
a[i] invece di *(a + i)
a -> b invece di (*a).b
foreach sintassi invece di digitare manualmente la sintassi dell'iteratore.
Tutto il sovraccarico dell'operatore è puro zucchero sintattico.
Sembra una definizione giusta e ragionevolmente inequivocabile?
"Zucchero sintattico" non è un termine rigorosamente definito. A seconda di chi chiedi, molto probabilmente otterrai uno dei seguenti tipi di definizioni:
Non sono sicuro nei campi dell'informatica, ma con il campo della logica ci sono i concetti di conservatività ed eliminabilità delle definizioni [ 1 ] che sembrano essere nella stessa vena.
Applicando la corrispondenza Curry-Howard, si potrebbe essere in grado di elaborare un concetto parallelo di "zucchero sintattico".