Syntactische suiker
In computertalen verwijst syntactische suiker naar toevoegingen aan de syntaxis die de uitdrukkingskracht van de taal niet vergroten maar het voor de programmeur wel makkelijker maken iets te programmeren of uit te drukken. Deze taalelementen geven een alternatieve en praktischere manier om iets te schrijven met behulp van een korte of meer bekende notatie. Deze notatie beïnvloedt de uitdrukkingskracht van het taal niet. Deze term is bedacht door Peter J. Landin.
Syntactische suiker kan gemakkelijk worden omgeschreven ("ontsuikerd") naar taalelementen die wel tot de kern van de taal behoren. Bij Landin was dat de lambdacalculus die uitgebreid werd met een paar operaties, zoals het toekennen van waarden (assignatie). De programmeertalen ML en Scheme zijn later ontworpen op basis van dit principe: deze talen bevatten een aantal essentiële taalconstructies waar syntactische suiker in uitgedrukt kan worden. 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 uitgedrukt kan worden in die basiselementen.
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, met name 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 makkelijkere notatie voor strings, een reeks tekens. In bijvoorbeeld Haskell kan de string "Wikipedia" als volgt geschreven worden: "Wikipedia". Dit is syntactische suiker aangezien een string in Haskell wordt voorgesteld als een lijst tekens (characters in het Engels). Deze string wordt eigenlijk geschreven als:
['W','i','k','i','p','e','d','i','a'].
Deze notatie voor een lijst is ook weer syntactische suiker: een lijst in Haskell is namelijk leeg (voorgesteld als []) of een lijst waar een element aan wordt toegevoegd (voorgesteld als e : lijst waarbij e het element is en ':' een operator 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 en niet prettig in gebruik. De toevoeging van syntactische suiker maakt het mogelijk de string als "Wikipedia" op te schrijven. Deze notatie is niet alleen makkelijker, het is ook een bekendere notatie aangezien deze notatie in veel programmeertalen wordt gebruikt om een string op te schrijven.
Arrays in C
Een ander voorbeeld zijn arrays in C. In C worden arrays geconstrueerd als blokken geheugen die opgevraagd kunnen worden vanaf een bepaald punt, namelijk het begin van de array. Het uitvoeren van berekeningen met pointers is echter lastig en foutgevoelig waardoor C de notatie a[i] mogelijk maakt voor iets wat eigenlijk als *(a + i) geschreven zou moeten worden. Op vergelijkbare wijze is a[i][j] makkelijker te begrijpen dan *(*(a + i) + j).
Lijstcomprehensies
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 omgeschreven naar code met andere taalconstructies.
De lijst met even getallen kan met lijstcomprehensie is Haskell genoteerd worden als:
[ x | x <- [0..], x `rem` 2 == 0 ]
Dit wordt omgeschreven naar:[1]
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.[2] Door het toevoegen van syntactische suiker wordt het lastiger om nauwkeurige foutmeldingen te geven als de programmeur een fout gemaakt heeft: een syntactisch element kan nu meerdere betekenissen hebben terwijl de compiler niet exact kan zien welke bedoeld wordt als er een fout gemaakt wordt.
Zo klaagt GHC over een ontbrekende instantie van Num Bool bij [ 3 + 3 | 4 + 4 ] (een onjuist gevormde lijstcomprehensie) terwijl waarschijnlijk [ 3 + 3, 4 + 4 ] (een lijst met elementen gescheiden door een komma) bedoeld werd. 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 (zoals een type-fout), dan dient de foutmelding de oorspronkelijke code met syntactische suiker te bevatten en niet de ontsuikerde versie (de code waar de syntactische suiker naartoe is geschreven).
Andere termen
- Syntactisch zout bestaat uit de taalelementen die het moeilijker maken om slechte code te schrijven. Deze taalelementen moeten door de programmeur worden geschreven om aan te geven dat hij weet waar hij mee bezig is in plaats van simpelweg iets op te schrijven of te specificeren. 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. Sommige programmeurs beschouwen type-declaraties van variabelen ook als syntactisch zout.
- Syntactische sacharine verwijst naar overbodige taalelementen die het programmeren niet makkelijker maken.
- Syntactische heroïne verwijst naar de taalelementen die op het eerste gezicht het programmeren vergemakkelijken maar daarna willen de programmeurs er steeds meer gebruik van maken. De term werd gebruikt met betrekking tot operator-overloading in een column van Rodney Bates. Door het veelvuldig gebruik van operator overloading wordt de code wel erg compact maar uiteindelijk is niemand meer in staat de code te begrijpen.
Bronnen, noten en/of referenties
|