iets wat je ziet bij generators die XSL gebruiken
Dat is werkelijk een vreselijke aanpak (dat ik dat vind had je waarschijnlijk al gelezen in het Conference .NET topic
). Er is zelfs een volledig
boek gepubliceerd over het genereren van Java source code op deze afschuwelijke manier.
Otis: Ik redeneerde zo: is er een simpele (belangrijk) taal te verzinnen waarbij je met een generieke generator, in minder statements dan de gegenereerde code, een generatieproces kunt beschrijven waarbij je code in een complexere taal kunt genereren met meer statements dan de beschrijving van de generator. Ik denk dat dat niet kan, helaas. (want dat zou inhouden dat je met een simpele taal, C++ kunt genereren dat dus complexer is dan de simpele generatiebeschrijving. En dan niet kleine programma's, maar alle mogelijke C++ code.
Hum .... Ik probeer je gedachte-experiment te volgen en ik denk dat ik begrijp wat je bedoelt. Ik denk dat het zinvol is om uit te leggen hoe ik code genereer. Dit is namelijk heel illustratief voor het probleem waar jij op doelt. Veel zul je al weten, maar je bent niet de enige die dit leest hoop ik
. Lees het alsjeblieft echt door, want ik weet zeker dat je het echt leuk vind als je het doorgelezen hebt en begrijpt (dat leidt ik af uit je werk aan LLBL).
Code kan je grofweg op twee manieren beschrijven: in
concrete syntax, de syntax waarin wij met z'n allen dagelijks programmeren in C++, PHP, Java, C# of wat dan ook, of in
abstracte syntax trees. Deze abstracte syntax is een representatie van de code in boomvorm die overeenkomt met de producties van context-vrije grammatica voor de taal, eventueel nog opgeleukt door het ontsuikeren van de toestand.
XML kan je eigenlijk sterk vergelijken met deze abstracte syntax, net zoals je Lisp sterk kan vergelijken met deze abstracte syntax (daar speelt wat leuks, maar dat is verder niet relevant
). XSLT als transformatie-taal voor XML zou je dus ook in kunnen zetten als een tranformatie taal voor abstract syntax trees.
De code-generatie met behulp van XSLT maakt gebruikt van
concrete syntax: de taal die je wilt genereren is min of meer exact opgenomen in XSLT (de syntax van XML zorgt uiteraard voor veel moeilijkheden). XSLT 'kent' deze taal niet en in feite is het dus gewoon bezig om pure tekst te genereren, zonder de structuur van deze tekst te snappen.
Je kan code-generatie met behulp van XSLT dit zien:
code:
1
2
3
| <xsl:template match=" ..... ">
<xsl:apply-templates select="a"/> + 3
</xsl:template> |
Hier tel je dus 3 op bij de apply-templates "a", wat dan weer een expressie zou moeten zijn (maar uiteraard gewoon tekst is. De aanpak die hier gekozen is, is eigenlijk vrij merkwaardig omdat ik juist de link heb gelegd (niet erg uitgebreid, maar dat heb ik wel eerder gedaan) tussen abstract syntax trees en XML. Er bestaat een sterke relatie tussen deze twee en XSLT is een transformatie-taal voor XML. Vreemd dus eigenlijk dat er opeens met pure tekst wordt gewerkt. Eigenlijk zou het logischer zijn om zo te werken:
code:
1
2
3
4
5
6
| <xsl:template match=" ..... ">
<plus>
<xsl:apply-templates select="a"/>
<int-const>3</int-const>
</plus>
</xsl:template> |
Deze structuur die je hier ziet, is ongeveer de structuur van een AST, zoals je die zou kunnen tegenkomen in een compiler of andere tools die op een taal werken. Uiteraard is dit verschrikkelijk verbose en zo mogelijk nog lelijker dan de oplossing met concrete syntax, maar conceptueel is het een stuk fraaier en logischer. Dat XML en XSLT een verbose syntax hebben is niet mijn probleem en ook niet het probleem van het probleem van code-generatie
.
Nu ga ik een grappige stap maken. Stratego is namelijk ook een transformatie-taal. Stratego is niet te vergelijken met XSLT, maar opereert ook op een soort XML-achtige structuur. Het gaat hier om ATermen, maar het idee hiervan ligt zo dicht bij XML dat we de verschillen wel kunnen negeren. Stratego is een stuk krachtiger en flexibeler dan XSLT, maar daardoor misschien ook een stukje complexer. Stratego gebruikt echter absoluut geen XML achtige syntax voor zijn eigen constructies, dus dat maakt het een stuk aantrekkelijker.
Stratego is een transformatie-taal die net als XSLT werkt met boom-achtige structuren: je transformeert dus de ene boom naar de andere. Stratego is speciaal bedoelt voor compilerbouw en (complexe) programma transformaties, dus over het algemeen transformeer je in Stratego een AST naar een AST. De taal waarop je werkt (als je Java code genereert Java), wordt ook wel de
object taal genoemd. De taal waarin je een tool implementeert die iets met een object taal doet, wordt ook wel de
meta taal genoemd.
Stratego werd in het verleden vooral gebruikt voor experimentele compilerbouw, programma optimalisaties en transformaties van de ene taal naar de andere, maar het kan ook prima ingezet worden voor code-generatie. Het grote nadeel hiervan is dat je al snel flinke lappen code krijgt bij code-generatie. Compilerbouw en programma-optimalisaties hebben meestal maar betrekking op vrij kleine delen van een AST, waardoor de AST structuren die je moet beschrijven vrij klein zijn. Bij code generatie ligt dit echt fundamenteel anders: daar 'explodeert' de code vaak.
Eelco Visser, de man achter Stratego en in het verleden een belangrijk persoon achter SGLR/SDF (komt later) kwam toen op een idee: waarom geen
concrete syntax gebruiken
. Het idee zal duidelijk zijn: in plaats van boom-structuren nemen we gewoon de concrete syntax van de
object taal en gebruiken deze om code te genereren in plaats van die verbose AST structuren.
Dit lijkt op het eerste gezicht misschien erg veel op de code-generatie met XSLT, maar de aanpak is fundamenteel verschillend. De concrete syntax is namelijk
suiker voor de echte AST structuren. At compile time wordt de concrete syntax dus omgezet naar de AST structuren, die je anders in had moeten tikken. De code die je genereert in je generator wordt dus 'begrepen' door de compiler voor Stratego. Als er een syntaxtische fout in zit (semantische fouten liggen anders) krijg je dus een melding. De output van het programma is ook gewoon een AST en dus geen concrete syntax. Het aardig is ook, dat je als je dat wilt ook nog steeds gebruik kan maken van de AST structuren als dat makkelijk is. Hierdoor kan je allerlei standaard tools die geschreven zijn voor programma-transformaties op een bepaalde taal nog steeds gebruiken.
De machinerie hierachter is vrij ingenieus. Stratego is namelijk onderdeel van XT, een verzameling tools voor programma tranformaties. SGLR en SDF zijn hier ook onderdeel van en vormen de kern van de gebruikte technieken. SDF is namelijk een syntax defintie formalisme (grammatica taal dus) met een aantal unieke eigenschappen: het support de
volledige klasse van context-vrije grammatica's, in tegenstelling vrijwel alle grammatica's die parser-generators accepteren. SGLR is de 'parser' in dit verhaal en maakt gebruik van Generalized LR parsing. Dit betekent dat er ambiguiteiten toegestaan zijn (maar uiteraard moeten deze wel worden opgelost, maar niet door verkrachting van je grammatica).
Heel leuk allemaal, maar het lijkt waarschijnlijk irrelevant. Het gevolg van de ondersteuning van deze volledige klasse van context-vrije grammatica's is echter dat SDF modulair kan zijn. Het probleem met alle (echte) subklassen van de context-vrije grammatica's is namelijk dat ze niet gesloten zijn onder de union operatie: als je twee grammatica's in zo'n subklasse samenvoegt is er geen garantie dat het resultaat in deze zelfde subklasse blijft. Omdat SDF de volledige klasse van context vrije grammatica's ondersteunt speelt dit probleem niet.
Dankzij deze unieke eigenschap kan je heel gemakkelijk talen
combineren. Dit is precies de techniek die gebruikt wordt: als je Java code wilt genereren met behulp van Stratego, combineer je de grammatica's van Stratego en Java (wat heel eenvoudig is: je importeert gewoon beide modules). Als SGLR een Stratego programma gaat parsen wat concrete syntax voor Java bevat, ontstaat er een AST die zowel constructies uit Java als contructies uit Stratego bevat. We zijn nu precies (ongeveer
) waar we wilden zijn.
Ik heb de laatste week gewerkt aan een code generator voor Java, die wat database toegangszooi, klassen voor domein objecten, modellen voor in GUIs en dergelijke genereert. Dit alles wordt gedaan vanuit een specificatie van het domein van een applicatie. Dit bespaart mij enorm veel werk omdat het steeds opnieuw implementerne van deze basis echt dagen (stom) werk kost per applicatie. Deze code generator is dus geschreven in Stratego, met concrete syntax voor Java. Hierdoor ontstaan extreem compacte en duidelijke specificaties, absoluut het lekkerste van het lekkerste op code generatie gebied. De resulterende AST wordt door pretty-printer omgezet naar concrete-syntax voor Java zodat de compiler het kan accepteren (deze pretty-printer maakt trouwens weer gebruik van concrete syntax van de BOX taal: een licht met XSL-FO vergelijkbaar iets om makkelijk code te kunnen pretty-printen naar 'boxen').
Je ziet dus wat er gebeurt: de grammatica van de object-taal (C++, Java, C#, BOX enz) wordt gecombineert met de grammatica van de meta-taal (Stratego, XSLT .... of..... Java, C#). Je krijgt dus inderdaad een
grotere taal, maar dit gebeurt puur op basis van grammatica's: als je een andere taal wilt generen heb je alleen maar een grammatica voor die taal nodig.
Er is geen enkele reden waarom je deze aanpak niet zo kunnen gebruiken in XSLT of zelfs in een imperatieve taal als Java of C#. Zelfs als de object-taal hetzelfde is als de meta-taal gaat het nog goed: je genereert dan dus C# code in C# met concrete syntax voor C# .... Dit doe jij in principe nu ook in LLBL, maar dan is er in feite er in de generator geen 'kennis' van de inhoud omdat je in feite stringetjes aan het plakken bent. Dit is dus te vergelijken met de aanpak in XSLT zoals die nu vaak wordt gepresenteerd, maar dan iets aantrekkelijker omdat C# nu eenmaal aantrekkelijker is dan XSLT
.
Het lijkt mij heel leuk om jouw LLBL om te zetten naar deze aanpak, maar er is 1 probleem: XT draait in principe alleen onder Unix/Linux/Cygwin/Mac OS X. Op zich is dat voor een tool wat je gebruikt niet zo'n probleem, maar het zal toch de echte toepassing van een generator voor .NET wat beperken als het niet onder MS Windows draait
.
Voorlopig dus alleen app-gen (kon zo snel niets beter verzinnen
): database laag generatie voor Java. Ik heb app-gen nog niet online staan, maar overweeg omdat het een uitermate krachtige oplossing is geworden wel om dit te gaan doen en het te documenteren. app-gen beschikt over een uitgekiend inclusie mechanisme om extra code op te kunnen nemen in de gegenereerde klassen. Je kan de code die gegenereert wordt dus nog op allerlei manieren uitbreiden, iets wat vaak een probleem is bij code-generatie. Je kan extra class of interface body declarations opnemen, je kan extra imports opnemen, je kan de klasse extra interfaces laten implementeren of een superklasse laten extenden (als de gegenereerde klasse dit al niet deed) enz.
Tot slot kan ik je nog wat leuks vertellen waar ik mee bezig ben: Embedded XML. Het genereren van XML in een applicatie is niet bepaald een lolletje. Zeker niet als je ook nog garanties wilt hebben van de well-formed ness van het resultaat. Hierdoor moet je tegen een XML library gaan praten en dat vraagt veel en onduidelijke code.
Het kan echter een stuk eenvoudiger: mix de
object taal XML met de
meta taal Java of C#. Je krijgt dan een taal die bestaat uit Java + XML. Je kan nu dus de echte syntax voor XML in Java of C# opnemen. Je kan door middel van een tool de embedded XML (die ook variabelen, methode aanroepen en dergelijke mag bevatten) omzetten naar een methode van jouw voorkeur om XML te genereren. De meest aantrekkelijk optie is dat het afvuren van events naar een SAX ContentHandler, gecombineerd met een pretty-printer voor XML. Je tikt dus
concrete syntax voor XML, maar je krijgt via code generatie krachtige en snelle code waarin de XML content wordt opgebouwd door het af te vuren naar een SAX ContentHandler.
Behalve in gewone applicaties die iets doen met XML, kan dit ook nog in bepaalde gevallen interessant zijn als een krachtig en eenvoudig alternatief voor JSP/ASP. Neem bijvoorbeeld Java Servlets: als je daar concrete syntax voor XHTML kan gebruiken, heb je een aardige manier om snel, correct en duidelijk XHTML code genereren, zonder dat er een serieuze nieuwe taal ontstaan is die je moet gaan leren (JSP). Dit Embedded XML heeft trouwens wel weer een grappige overeenkomst met embedded SQL, wat je in principe ook erg fraai op deze manier zou kunnen implementeren.
Pfff... Ik zit nu al zo lang te tikken dat ik maar stop
. Ik hoop dat je m'n verhaal over de fraaie tools die je zou kunnen toepassen bij code-generatie kan waarderen, want het heeft me zowat een uur gekost
. Als je meer wilt weten over meta-programming met concrete syntax kan je dit artikel lezen:
http://www.stratego-langu...gWithConcreteObjectSyntax
/u/2046/pooh2.png?f=community)
.
: bijna 30 jaar geleden zo exact schrijven over de huidige stand van zaken 
. Hierbij vergeleken was George Orwell toch wel een enorme prutser 
:strip_exif()/u/31626/eend.gif?f=community)
):strip_icc():strip_exif()/u/35767/images.jpg?f=community)
/u/27299/hoofd.png?f=community)
.:strip_exif()/u/11874/clownsmall.gif?f=community)
:strip_exif()/u/11775/SoulTaker.gif?f=community)
. Bovendien is het nut hiervan beperkt omdat SGLR (de parser) geschreven is in C en vrij heftig materiaal is.