Syntactische suiker

In computertalen verwijst syntactische suiker naar toevoegingen aan de syntaxis die er niet voor zijn bedoeld de mogelijkheden van de taal te vergroten, maar om het de programmeur mogelijk te maken sommige delen beknopter te kunnen programmeren. Het is duidelijk dat suiker hier in overdrachtelijke zin is bedoeld. Deze taalelementen geven een alternatieve en praktischere manier om iets te programmeren met behulp van een korte of meer bekende notatie. Deze notatie beïnvloedt de uitdrukkingskracht van de taal niet. PJ Landin is op de naam gekomen.

Syntactische suiker kan gemakkelijk worden omgeschreven naar broncode, waarin de elementen wel tot de kern van de taal behoren. Bij Landin was dat de lambdacalculus die met een paar operaties werd uitgebreid, zoals het toekennen van waarden. De programmeertalen ML en Scheme zijn later ontworpen op basis van dit principe: deze talen bevatten een aantal essentiële taalconstructies, die door middel van syntactische suiker beknopter kunnen worden geformuleerd. In de wiskunde is het een gebruikelijk principe om te beginnen met zo weinig mogelijk basiselementen en de meeste berekeningen uit te voeren in een gemakkelijkere notatie, die in die basiselementen kan worden uitgedrukt.

Voorbeelden

Infixnotatie van operatoren

De meeste programmeertalen maken het mogelijk om eenvoudige wiskundige berekeningen in infixnotatie te noteren, zoals i + 3. Veel van deze talen, vooral functionele programmeertalen, voeren deze berekeningen uit door een functie aan te roepen waardoor de infixnotatie eigenlijk syntactische suiker is voor bijvoorbeeld add i 3.

Strings in Haskell

Veel programmeertalen bevatten een beknopte notatie voor tekenreeksen of strings, een reeks karakters. In bijvoorbeeld Haskell kan Wikipedia ook op die manier worden geschreven, als Wikipedia. Dit is syntactische suiker aangezien een string in Haskell wordt voorgesteld als een lijst karakters. Deze string wordt eigenlijk geschreven als:

['W','i','k','i','p','e','d','i','a']

Deze notatie voor een lijst is dus ook weer syntactische suiker: een lijst in Haskell is namelijk leeg, geschreven als [], of een lijst waar een element aan wordt toegevoegd, geschreven als e : lijst waarbij e het element is en ':' een bewerking om een element op kop van een lijst te zetten. De notatie [1,2,3] is bijvoorbeeld syntactische suiker voor 1:2:3:[]. De string Wikipedia wordt, ontdaan van alle syntactische suiker, als volgt geschreven:

'W':'i':'k':'i':'p':'e':'d':'i':'a':[]

Deze notatie is omslachtig. De toevoeging van syntactische suiker maakt het mogelijk de string als Wikipedia te schrijven. Deze notatie is niet alleen gemakkelijker, het is ook een bekendere notatie aangezien deze notatie in veel programmeertalen wordt gebruikt om een tekenreeks of string op te schrijven.

Arrays in C

Een ander voorbeeld zijn arrays in C. In C worden arrays geconstrueerd als blokken geheugen die vanaf een bepaald punt kunnen worden opgevraagd, namelijk het begin van de array. Het uitvoeren van berekeningen met pointers is lastig en foutgevoelig waardoor C de notatie a[i] mogelijk maakt voor iets wat eigenlijk als *(a + i) zou moeten worden geschreven. a[i][j] is op vergelijkbare wijze gemakkelijker te begrijpen dan *(*(a + i) + j).

Lijstcomprehensies

Zie Lijstcomprehensie voor het hoofdartikel over dit onderwerp.

Met een lijstcomprehensie is het mogelijk een lijst te noteren met een notatie die lijkt op de wiskundige notatie voor verzamelingen. Deze notatie wordt door de compiler of interpreter eerst op een manier geschreven, die door de computer kan worden verwerkt. De lijst met even getallen kan met lijstcomprehensie is Haskell genoteerd worden als:

[ x | x <- [0..], x `rem` 2 == 0 ]

Dit wordt omgeschreven naar:

let ok x = if x `rem` 2 == 0 then [x] else []
 ok _ = []
in concatMap ok [0..]

wat hetzelfde resultaat oplevert.

Nadelen

Het aanbrengen van syntactische suiker brengt ook enkele nadelen met zich mee. Door het toevoegen van syntactische suiker wordt het lastiger om nauwkeurige foutmeldingen te geven als de programmeur een fout heeft gemaakt: een syntactisch element kan nu verschillende betekenissen hebben, terwijl de compiler niet exact kan zien welke wordt bedoeld als er een fout is gemaakt.

Zo geeft de Glasgow Haskell Compiler een melding wanneer Num Bool bij [ 3 + 3 | 4 + 4 ] ontbreekt, dus een verkeerd geformuleerde lijstcomprehensie, terwijl waarschijnlijk [ 3 + 3 , 4 + 4 ], een lijst met elementen gescheiden door een komma, werd bedoeld. Evenzo geeft [ x + 3, x <- [1..10] ] een parse error in plaats van een melding over het gebruik van een komma in plaats van een verticale streep.

Een gerelateerd probleem is dat de compiler bij een foutmelding ook rekening moet houden met het feit dat er syntactische suiker is gebruikt. Zoals hierboven beschreven wordt syntactische suiker omgeschreven naar andere taalconstructies. Mocht zich hier een fout in voordoen, bijvoorbeeld een typefout, dan dient de foutmelding de oorspronkelijke code met syntactische suiker te bevatten en niet de al herschreven code.

Varianten

• Syntactisch zout, van zouten, bestaat uit de taalelementen die het moeilijker maken om slechte broncode te schrijven. Een vereiste om het einde van een lus aan te geven met bijvoorbeeld end if, end while of end do in plaats van alleen end wordt algemeen beschouwd als syntactisch zout. Het declareren van het datatype van variabelen kan als een voorbeeld van syntactisch zout worden gegeven.
• Syntactische sacharine, van sacharine, verwijst naar overbodige taalelementen die het programmeren niet gemakkelijker maken.
• Syntactische heroïne, van heroïne, verwijst naar de taalelementen die op het eerste gezicht het programmeren eenvoudiger maken, maar daarna willen de programmeurs er steeds meer gebruik van maken. Het werd bijvoorbeeld gebruikt met betrekking tot operator-overloading in een column van Rodney Bates. Door het veelvuldig gebruik van operator overloading wordt de code wel beknopt, maar is op het laatst niemand meer in staat de code te begrijpen.

Voetnoten