Koen Vervloesem
2 November 2010

Domeinspecifieke talen zijn in veel gevallen handige instrumenten in modelgedreven softwareontwikkeling. Een tool waarover je tegenwoordig vaak hoort in de context van DSL‘s is XText, een onderdeel van de opensource ontwikkelomgeving Eclipse. Tijd om hier eens naar te kijken en enkele gebruikers aan het woord te laten.

Een domeinspecifieke taal (domain-specific language of kortweg DSL) wordt, zoals het woord het al zegt, ontwikkeld om problemen in een specifiek domein op te lossen. Door zich op het domein toe te spitsen, kan een DSL expressiever zijn dan een algemene programmeertaal. En doordat de code op het abstractieniveau van het probleemdomein wordt uitgedrukt, is deze quasi zelfdocumenterend en eenvoudig te begrijpen door domeinexperts. Dat heeft een positief effect op de kwaliteit, onderhoudbaarheid en herbruikbaarheid van de code. Een nadeel is dat een DSL ontwikkelen voor een meer dan triviale taal heel wat tijd vraagt, en dat je het gebruik van de taal dan nog moet kunnen integreren in je favoriete ontwikkelomgeving.

Een van de tools die een totaaloplossing voor DSL‘s wil bieden en dit volledig integreert in de ontwikkelomgeving Eclipse is XText. Dit opensource pakket wordt ontwikkeld door het Duitse bedrijf Itemis, dat zich focust op modelgedreven softwareontwikkeling. In XText definieer je een domeinspecifieke taal, waarna het programma op basis van de grammatica een volledige taalinfrastructuur genereert, zoals parsers, syntax checking, linkers, compilers, een AST-metamodel en een Eclipse-teksteditor. Zo biedt de editor voor je taal out-of-the-box syntax highlighting en code completion, die eventueel zelf nog naar smaak zijn aan te passen. Verder zijn alle features die je gewoon bent van de Eclipse-editor nog altijd aanwezig. XText is onderdeel van het Eclipse Modeling Project en is nauw geïntegreerd met de andere tools hierin, zoals XPand en XTend. Eclipse 3.6.0 (’Helios‘) van juni 2010 luidde XText 1.0 in.

Ruby

Volgens Klaas Gadeyne van FMTC, waar XText al een tijdje op de radar staat, is de tool een echte hefboom in de tekstgebaseerde DSL-wereld: ’Tekstgebaseerde DSL‘s hebben duidelijk een aantal voordelen tegenover grafische DSL‘s: hun expressiemogelijkheden zijn typisch uitgebreider en je kunt de klassieke versiebeheertools voor je code hergebruiken. Voordat XText op de markt kwam, was het niet zo eenvoudig om een DSL te creëren met editor-ondersteuning, syntax highlighting en dergelijke. Dan werd al eens besloten om in de plaats een grafische DSL te gebruiken; een grafische omgeving biedt nog altijd een lagere instapdrempel om gebruikers met een nieuwe syntax bekend te maken. In de praktijk zitten er echter heel wat addertjes onder het gras, is onze ervaring. We zijn dan ook van plan om op korte termijn XText te evalueren in ons onderzoek naar modelgedreven systeemontwikkeling van mechatronische machines.‘

Het Gentse Sigasi, dat een Eclipse-gebaseerde VHDL-ontwikkelomgeving ontwikkelt, is pas begonnen met XText te evalueren, na een presentatie van XText-projectleider Sven Efftinge van Itemis op de Belgian Eclipse User Group eind augustus. ’Drie van ons gingen daarheen en ze kwamen enthousiast terug‘, zegt Sigasi-CEO Philippe Faes. ’Ik stond daar wat kritisch tegenover, want we hebben met Sigasi Hardware Development Toolkit een bestaand product, en dit op een nieuw raamwerk baseren heeft toch wel wat risico‘s.‘

Sigasi besloot echter om XText te evalueren en Faes was blij verrast met die eerste evaluatie: ’Je krijgt veel functionaliteit out-of-the box: niet alleen syntax highlighting en intelligente code completion, maar ook type-time compiling. Je krijgt dan foutmeldingen te zien terwijl je je code typt. Al deze features moesten wij tot nu toe zelf programmeren.‘

Itemis_Sven_Efftinge
Sven Efftinge van het Duitse Itemis is projectleider van XText.

Ook Jan Veldeman van de Leuvense detectorontwikkelaar Xenics is tevreden over XText: ’In het begin schreef ik zelf DSL‘s in Ruby, bijvoorbeeld voor registerbeschrijvingen van camera‘s, maar daarmee kun je vaak nog fouten maken en voor anderen is het niet altijd eenvoudig om te lezen. Toen ik over XText hoorde, heb ik het voor een van onze projecten gebruikt. Door stap voor stap meer functionaliteit toe te voegen, werd de kracht van XText pas echt duidelijk: je kunt automatisch modelklassen uit de grammatica genereren, automatisch links leggen tussen de klassen aan de hand van de grammatica, aanpasbare scoping definiëren, enzovoort.‘

Een belangrijk voordeel van XText is volgens Veldeman dat het integreert met andere tools van het Eclipse Modeling Framework. Zo kun je vanuit je model ook een grafische voorstelling genereren. Door grafisch je taal te bekijken, kun je zien of er bijvoorbeeld genoeg overerving is. ’Omwille van deze goede ervaringen zal XText in de toekomst een basisonderdeel worden van de infrastructuur in al onze embedded-softwareprojecten‘, besluit Veldeman.

Routers

Een veelgehoorde kritiek rond XText is dat het niet voor echt grote programmeertalen wordt gebruikt. Efftinge pareert dit argument met twee voorbeelden. Enerzijds is er Artext, een taal voor de specificatie van Autosar-systemen. BMW speelt een grote rol in dit project. ’In de automotive-industrie heb je gigantische projecten, en Autosar-modellen hebben grote specificaties en complexe metamodellen. Artext is gecreëerd met XText, en dat schaalt heel goed‘, beklemtoont hij.

XText_Screenshot_01
XText genereert op basis van de grammatica van een taal een Eclipse-editor met syntax highlighting en code completion.

Een ander project is AxDT, een verzameling van plug-ins voor Eclipse die toelaten om Actionscript 3-code te schrijven in de opensource ontwikkelomgeving. Adobe gebruikt deze scripttaal in zijn Flash Player. Het is een dialect van Ecmascript (de gestandaardiseerde versie van Javascript). De nieuwste versie van AxDT is gebaseerd op XText. Volgens Efftinge kun je met de tool dus ook complexe programmeertalen definiëren.

Andere voorbeelden kan hij niet met naam noemen, omdat het om klanten gaat die er nog niet mee naar buiten willen komen, maar hij somt een breed gamma aan toepassingsdomeinen op: ’Een van onze klanten is PL/SQL aan het implementeren, een andere is een ontwikkelomgeving aan het maken voor een bestaand financieel product met meer dan honderd domeinspecifieke talen. Verder hebben we klanten die XText gebruiken om windturbines voor simulaties te beschrijven, om routers te configureren en om Cad-systemen te besturen.‘

Vanaf nul

XText is vooral geschikt wanneer je from scratch een infrastructuur voor een programmeertaal of DSL wilt ontwikkelen. Volgens consultant Meinte Boersma kan dat voor kleine talen zelfs heel snel: ’Als je een goed idee hebt van je taal en het om een zogenaamde ’little language‘ gaat om het met de woorden van Martin Fowler te zeggen, dan heb je echt in enkele minuten tijd een werkende parser en Eclipse-editor gegenereerd. XText neemt niet de moeilijkheid van het maken van een taal weg, maar wel al die tijdrovende boilerplate-technologie er rond.‘

Als je al een werkende grammatica voor een andere parsergenerator hebt en heel wat bestaande code, dan is het natuurlijk meer werk, omdat je dit alles moet herschrijven. In die situatie zit Sigasi nu, zegt Faes: ’We hebben al een uitgebreide codebase, en moeten dus heel wat bestaande code zoals onze VHDL-parser omzetten naar XText als we het willen gebruiken. Een van onze mensen heeft hier nu een maand voor uitgetrokken om te zien hoe ver we geraken met één manmaand.‘

Een ander punt om rekening mee te houden, is dat de standaardkeuzes van XText niet altijd goed overeenkomen met elke taal. Als je vanaf nul een DSL ontwerpt met XText in het achterhoofd, ga je vanzelf wel de standaardkeuzes van XText voor naamconventies, scoping-regels en dergelijke overnemen, maar voor bestaande talen kan dit niet, waarschuwt Faes: ’De XText-defaults komen niet overeen met de syntax van VHDL. Volgens de ontwikkelaars is alles in XText wel volledig configureerbaar, ook de defaults, maar we moeten nog inschatten hoeveel werk dat allemaal is. Voorlopig zien we echter nog geen grote showstoppers, en ik denk dat XText hetgene is waarop we al lang aan het wachten waren.‘

Volgens Boersma hangt er aan de flexibiliteit van XText ook een nadeel: ’De leercurve is in het begin vrij vlak en je kunt veel zaken gemakkelijk realiseren, maar als je die flexibiliteit wilt gebruiken en geavanceerdere zaken wilt doen, moet je echt wel diep in het raamwerk duiken en er meer tijd in steken. De documentatie is ook niet altijd zo eenvoudig te begrijpen, waardoor je het twee keer moet lezen voor je begrijpt waar het om gaat.‘

Diff en Merge

Uiteraard loont het de moeite om ook naar andere tools te kijken. Efftinge noemt Meta Programming System (MPS) van Jetbrains zijn ’interessantste concurrent‘. Het grootste verschil is dat MPS je code niet als tekst opslaat maar in een XML-formaat dat de abstracte syntax voorstelt. De editor toont dan wel weer een tekstversie. ’Het grootste voordeel van de aanpak van MPS is dat language composition eenvoudiger is dan in XText. Wij ondersteunen dat ook wel, maar je moet dan met syntactische ambiguïteiten rekening houden‘, geeft Efftinge toe.

Het nadeel van deze zogenaamde projection-based aanpak van MPS is dat er een zekere lock-in is: je kunt je broncode enkel bekijken en aanpassen in MPS. In XText daarentegen bestaat je broncode gewoon uit tekstbestanden in de concrete syntax die je hebt gekozen voor je programmeertalen, en deze kun je verwerken met de klassieke tekstgebaseerde tools zoals editors en Diff en Merge.

Maar uiteindelijk moet je ook verder kijken dan de functionaliteit en rekening houden met wat de markt aanbiedt. In de laatste jaren heeft Eclipse veel momentum gekregen, onder meer in de wereld van embedded-softwareontwikkeling. Alleen al dit momentum is volgens Gadeyne van FMTC een belangrijk criterium om voor XText te kiezen: ’Het Eclipse-ecosysteem biedt heel veel aan, en ook het Eclipse Modeling Project gaat de goede richting uit. Als we binnen FMTC ooit een tekstgebaseerde DSL willen ontwikkelen, zal XText het eerste zijn dat we evalueren.‘