Kompilator -kompilator - Compiler-compiler

Inte att förväxla med självvärdskompilator eller källa-till-källkompilator .

Inom datavetenskap är en kompilator-kompilator eller kompilatorgenerator ett programmeringsverktyg som skapar en parser , tolk eller kompilator från någon form av formell beskrivning av ett programmeringsspråk och en maskin.

Den vanligaste typen av kompilator-kompilator kallas mer exakt en parsergenerator och hanterar bara syntaktisk analys: dess inmatning är en grammatik , vanligtvis skriven i Backus – Naur-form (BNF) eller utökad Backus – Naur-form (EBNF) som definierar syntax för ett programmeringsspråk; och dess utmatning är källkod för en parser för programmeringsspråket. Parsergeneratorer hanterar inte semantiken i programmeringsspråket eller generering av maskinkod för målmaskinen.

En metakompilerare är ett mjukvaruutvecklingsverktyg som främst används vid konstruktion av kompilatorer , översättare och tolkar för andra programmeringsspråk. Ingången till en metakompilator är ett datorprogram skrivet i ett specialiserat programmeringsmetallspråk som huvudsakligen är utformat för konstruktion av kompilatorer. Språket för kompilatorn som produceras kallas objektspråk . Den minimala ingången som producerar en kompilator är ett metaprogram som specificerar objektspråkets grammatik och semantiska transformationer till ett objektprogram .

Varianter

En typisk parsergenerator associerar körbar kod med var och en av grammatikreglerna som bör köras när dessa regler tillämpas av parsern. Dessa kodbitar kallas ibland för semantiska handlingsrutiner eftersom de definierar semantiken för den syntaktiska strukturen som analyseras av parsern. Beroende på vilken typ av parser som ska genereras kan dessa rutiner konstruera ett parningsträd (eller abstrakt syntaxträd ) eller generera körbar kod direkt.

En av de tidigaste (1964), överraskande kraftfulla versionerna av kompilator-kompilatorer är META II , som accepterade en analytisk grammatik med utmatningsfaciliteter som producerar stapelmaskinskod , och kan kompilera sin egen källkod och andra språk.

Bland de tidigaste programmen i de ursprungliga Unix- versionerna som byggdes på Bell Labs var det tvådelade lex- och yacc- systemet, som normalt användes för att mata ut C-programmeringsspråkskod , men hade ett flexibelt utmatningssystem som kan användas för allt från programmeringsspråk till textfilkonvertering. Deras moderna GNU -versioner är flex och bison .

Vissa experimentella kompilator-kompilatorer tar som input en formell beskrivning av programmeringsspråksemantik, vanligtvis med denotationssemantik . Detta tillvägagångssätt kallas ofta "semantikbaserad kompilering" och var föregångare av Peter Mosses Semantic Implementation System (SIS) 1978. Men både den genererade kompilatorn och koden som den producerade var ineffektiva i tid och rum. Inga produktionskompilatorer är för närvarande byggda på detta sätt, men forskningen fortsätter.

Projektet Production Quality Compiler-Compiler ( PQCC ) vid Carnegie Mellon University formaliserar inte semantik, men har en halvformell ram för maskinbeskrivning.

Kompilator-kompilatorer finns i många smaker, inklusive nedifrån och upp-omskrivningsmaskingeneratorer (se JBurg ) som används för att kakla syntaxträd enligt en omskrivningsgrammatik för kodgenerering och attribut grammatiska parsergeneratorer (t.ex. ANTLR kan användas för samtidig typkontroll, konstant förökning och mer under analysfasen).

Metakompilatorer

Metakompilatorer minskar uppgiften att skriva kompilatorer genom att automatisera de aspekter som är desamma oavsett objektspråk . Detta möjliggör utformning av domänspecifika språk som är lämpliga för specifikationen av ett visst problem. En metacompiler reducerar kostnaden för att producera översättare för sådana domänspecifika objektspråk till en punkt där det blir ekonomiskt möjligt att inkludera i lösningen av ett problem en domän-specifikt språk design.

Eftersom en metakompilers metallspråk vanligtvis kommer att vara ett kraftfullt sträng- och symbolbehandlingsspråk, har de ofta starka applikationer för applikationer för allmänt bruk, inklusive att generera ett brett utbud av andra programvaruteknik- och analysverktyg.

Förutom att vara användbar för domänspecifik språkutveckling är en metakompilerare ett utmärkt exempel på ett domenspecifikt språk, utformat för domänen kompilatorskrivning.

En metakompilator är ett metaprogram som vanligtvis är skrivet på ett eget metaspråk eller ett befintligt datorprogrammeringsspråk. Processen för en metakompilator, skriven i sin egen metaspråk, som sammanställer sig själv, motsvarar självkompileraren . De vanligaste kompilatorer som skrivs idag är kompilatorer som är värd för sig själv. Self-hosting är ett kraftfullt verktyg av många metakompilatorer, vilket gör det enkelt att förlänga sin egen metaprogrammeringsmetaspråk. Funktionen som separerar en metakompilator bortsett från andra kompilatorkompilatorer är att den tar in ett specialiserat metaprogrammeringsspråk som beskriver alla aspekter av kompilatorns drift. Ett metaprogram som produceras av en metakompilator är ett lika komplett program som ett program skrivet i C ++ , BASIC eller något annat generellt programmeringsspråk . Den metaprogrammering meta är en kraftfull egenskap möjliggör enklare utveckling av dator programmeringsspråk och andra datorverktyg. Kommandoradsprocessorer, textsträngtransformation och analys kodas enkelt med hjälp av metaprogrammeringsmetallspråk för metakompilatorer.

En fullfjädrad utvecklingspaket innehåller en länk och en körtid stöd bibliotek . Vanligtvis behövs ett maskinorienterat systemprogrammeringsspråk , till exempel C eller C ++, för att skriva supportbiblioteket. Ett bibliotek bestående av supportfunktioner som behövs för kompileringsprocessen slutför vanligtvis hela metakompilatorpaketet.

Betydelsen av metacompiler

Inom datavetenskap används vanligtvis prefixet meta för att betyda ungefär (sin egen kategori) . Till exempel är metadata data som beskriver annan data. Ett språk som används för att beskriva andra språk är ett metallspråk . Meta kan också betyda på en högre abstraktionsnivå . Ett metallspråk fungerar på en högre abstraktionsnivå för att beskriva egenskaper hos ett språk. Backus – Naur -form (BNF) är en formell metallspråk som ursprungligen användes för att definiera ALGOL 60 . BNF är ett svagt metallspråk , för det beskriver bara syntaxen och säger ingenting om semantiken eller meningen. Metaprogrammering är att skriva datorprogram med förmågan att behandla program som deras data. En metakompilator tar som inmatning ett metaprogram skrivet i ett specialiserat metallspråk (en högre nivå abstraktion) speciellt utformad för metaprogrammering . Utdata är ett körbart objektprogram.

En analogi kan dras: Att som en C ++ kompilator tar som indata en C ++ programmering språkprogram, en meta tar kompilator som indata en meta programmeringsmeta program.

Framåt metakompilator

Många förespråkare för språket Forth kallar processen att skapa en ny implementering av Forth en metakompilering och att den utgör en metakompilator. Forth -definitionen av metakompilator är:

"En metakompilator är en kompilator som bearbetar sin egen källkod, vilket resulterar i en körbar version av sig själv."

Denna Forth -användning av termen metakompilator är omtvistad i vanlig datavetenskap. Se Forth (programmeringsspråk) och History of compiler construction . Själva Forth-processen för att sammanställa sig själv är en kombination av att en Forth är ett självvärdigt utbyggbart programmeringsspråk och ibland tvärkompilering , sedan länge etablerad terminologi inom datavetenskap. Metakompilatorer är ett generellt kompilatorskrivningssystem. Förutom att Forth-metakompilatorkonceptet inte går att skilja från självvärdigt och utbyggbart språk. Den faktiska processen agerar på en lägre nivå och definierar en minsta delmängd av fjärde ord , som kan användas för att definiera ytterligare ytterligare ord. En full Forth -implementering kan sedan definieras från basuppsättningen. Det här låter som en bootstrap -process. Problemet är att nästan alla språkkompilatorer för allmänna ändamål också passar beskrivningen av metakompilatorn Forth.

När (self-hosting compiler) X behandlar sin egen källkod, vilket resulterar i en körbar version av sig själv, är X en metakompilator.

Ersätt bara X med något vanligt språk, C, C ++, Pascal , COBOL , Fortran , Ada , Modula-2 , etc. Och X skulle vara en metakompilator enligt Forth-användningen av metakompilator. En metakompilator fungerar på en abstraktionsnivå ovanför kompilatorn den kompilerar. Den fungerar bara på samma (självvärdskompilator) nivå när den kompilerar sig själv. Man måste se problemet med denna definition av metakompilator. Det kan tillämpas på de flesta språk.

Men när man undersöker begreppet programmering i Forth, lägger man till nya ord i ordlistan, är utökningen av språket på detta sätt metaprogrammering. Det är denna metaprogrammering i Forth som gör den till en metakompilator.

Programmering i Forth är att lägga till nya ord till språket. Att ändra språk på detta sätt är metaprogrammering . Forth är en metakompilator eftersom Forth är ett språk som är särskilt utformat för metaprogrammering. Programmering i Forth förlänger Forth genom att lägga till ord i Forths ordförråd skapar en ny Forth -dialekt . Forth är en specialiserad metakompilator för Forth -språkdialekter.

Historia

Den första kompilator-kompilatorn som använde det namnet skrevs av Tony Brooker 1960 och användes för att skapa kompilatorer för Atlas- datorn vid University of Manchester , inklusive Atlas Autocode- kompilatorn.

Metakompilatorernas tidiga historia är nära knuten till historien om SIG/PLAN Working Group 1 on Syntax Driven Compilers. Gruppen startades främst genom insats av Howard Metcalfe i Los Angeles -området. Hösten 1962 konstruerade Howard Metcalfe två kompilatorskrivartolkar. En använde en botten-till-topp-analysteknik baserad på en metod som beskrivs av Ledley och Wilson. Den andra använde en top-to-bottom-metod baserad på ett arbete av Glennie för att generera slumpmässiga engelska meningar från en kontextfri grammatik.

Samtidigt beskrev Val Schorre två "metamaskiner". En generativ och en analytisk. Den generativa maskinen implementerades och producerade slumpmässiga algebraiska uttryck. Meta I den första metakompilatorn implementerades av Schorre på en IBM 1401 vid UCLA i januari 1963. Hans ursprungliga tolkar och metamaskiner skrevs direkt på ett pseudomaskinspråk. META II skrevs emellertid i ett metallspråk på högre nivå som kunde beskriva sin egen sammanställning till pseudomaskinens språk.

Lee Schmidt vid Bolt, Beranek och Newman skrev en metakompilator i mars 1963 som använde en CRT-display på tidsdelande PDP-l. Denna kompilator producerade faktisk maskinkod snarare än tolkningskod och var delvis bootstrapped från Meta I.

Schorre startade Meta II från Meta I under våren 1963. Tidningen om det raffinerade metakompilatorsystemet som presenterades vid Philadelphia ACM -konferensen 1964 är det första dokumentet om en metakompilator som finns som allmän referens. Syntaxen och implementeringstekniken för Schorres system lade grunden för de flesta system som följde. Systemet implementerades på en liten 1401 och användes för att implementera ett litet ALGOL -liknande språk.

Många liknande system följde omedelbart.

Roger Rutman från AC Delco utvecklade och implementerade LOGIK, ett språk för logisk designsimulering, på IBM 7090 i januari 1964. Denna kompilator använde en algoritm som producerade effektiv kod för booleska uttryck.

En annan uppsats i ACM -förfarandet 1964 beskriver Meta III , utvecklat av Schneider och Johnson vid UCLA för IBM 7090. Meta III representerar ett försök att producera effektiv maskinkod för en stor klass av språk. Meta III implementerades helt i monteringsspråk. Två kompilatorer skrevs i Meta III, CODOL, en kompilatorskrivande demonstrationskompilator och PUREGOL, en dialekt av ALGOL 60. (Det var ren gallring att kalla det ALGOL).

Sent 1964 startade Lee Schmidt upp metakompilatorn EQGEN, från PDP-l till Beckman 420. EQGEN var ett logiskt ekvationsgenererande språk.

År 1964 inledde System Development Corporation en stor insats för att utveckla metakompilatorer. Denna insats inkluderar kraftfulla metakompilatorer, Bookl och Book2 skrivna i Lisp som har omfattande trädsökning och säkerhetskopiering. En utväxt av ett av Q-32- systemen vid SDC är Meta 5. Meta 5-systemet innehåller säkerhetskopiering av ingångsströmmen och tillräckligt med andra faciliteter för att analysera alla kontextkänsliga språk. Detta system släpptes framgångsrikt till ett stort antal användare och hade många andra strängmanipuleringsapplikationer än kompilering. Den har många genomarbetade push-down-stackar, attributinställningar och testfaciliteter och utmatningsmekanismer. Att Meta 5 framgångsrikt översätter JOVIAL -program till PL/I -program visar dess kraft och flexibilitet.

Robert McClure på Texas Instruments uppfann en kompilator-kompilator som heter TMG (presenterades 1965). TMG användes för att skapa tidiga kompilatorer för programmeringsspråk som B , PL/I och ALTRAN . Tillsammans med metacompiler Val Schorre, det var en tidig inspiration för det sista kapitlet i Donald Knuth 'är The Art of Computer Programming .

LOT -systemet utvecklades under 1966 vid Stanford Research Institute och modellerades mycket nära efter Meta II. Den hade nya specialkonstruktioner som gjorde det möjligt att generera en kompilator som i sin tur skulle kunna kompilera en delmängd av PL/I. Detta system hade omfattande statistikinsamlingsmöjligheter och användes för att studera egenskaperna från top-down analys.

SIMPLE är ett specialiserat översättarsystem som är utformat för att underlätta skrivandet av förprocessorer för PL/I, SIMPLE, skrivet i PL/I, består av tre komponenter: En chef, en syntaxanalysator och en semantisk konstruktör.

Den träd META kompilator har utvecklats vid Stanford Research Institute i Menlo Park, Kalifornien. April 1968. Den tidiga metakompilatorhistoriken är väl dokumenterad i TREE META -manualen. TREE META parallellt med några av SDC -utvecklingen. Till skillnad från tidigare metakompilatorer separerade den semantiska bearbetningen från syntaxbehandlingen. Syntax reglerna träd bygga verksamhet som kombinerade erkända språkelement med trädnoder. Trädstrukturrepresentationen för ingången behandlades sedan med en enkel form av ojämna regler. De ojämna reglerna använde nodigenkänning och attributprovning som vid matchning resulterade i att den associerade åtgärden utfördes. Dessutom kan trädelement också testas i en ojämn regel. Ojämna regler var också ett rekursivt språk som kunde kalla ojämförliga regler som passerade delar av ditt träd innan åtgärden av den ojämna regeln utfördes.

Konceptet med metamaskinen som ursprungligen presenterades av Glennie är så enkelt att tre hårdvaruversioner har designats och en faktiskt implementerats. Det senare vid Washington University i St. Louis. Denna maskin är byggd av makro-modulära komponenter och har för instruktioner de koder som beskrivs av Schorre.

CWIC (Compiler for Writing and Implementing Compilers) är den sista kända Schorre -metakompilatorn. Det utvecklades på Systems Development Corporation av Erwin Book, Dewey Val Schorre och Steven J. Sherman Med full effekt av (lisp 2) kunde ett listbehandlingsspråksoptimeringsalgoritmer fungera på syntaxgenererade listor och träd före kodgenerering. CWIC hade också en symboltabell inbyggd i språket.

Med uppkomsten av domänspecifika språk och behovet av parsergeneratorer som är enkla att använda, lätta att förstå och lätta att underhålla, blir metakompilatorer ett värdefullt verktyg för avancerade programvarutekniska projekt.

Andra exempel på parsergeneratorer i yacc -venen är ANTLR , Coco/R , CUP, GNU Bison , Eli, FSL, SableCC , SID (Syntax Improving Device) och JavaCC . Även om de är användbara tar rena parsergeneratorer bara upp den analyserande delen av problemet med att bygga en kompilator. Verktyg med bredare omfattning, till exempel PQCC , Coco/R och DMS Software Reengineering Toolkit ger avsevärt stöd för svårare efterinpassningsaktiviteter som semantisk analys, kodoptimering och generering.

Schorre metallspråk

De tidigaste Schorre -metakompilatorer, META I och META II, utvecklades av D. Val Schorre vid UCLA. Andra Schorre -baserade metakompilatorer följde. Var och en lägger till förbättringar för språkanalys och/eller kodgenerering.

I programmering är det vanligt att använda programmeringsspråksnamnet för att referera till både kompilatorn och programmeringsspråket, i sammanhanget som skiljer betydelsen. Ett C ++ - program sammanställs med en C ++ - kompilator. Det gäller också i det följande. Till exempel är META II både kompilatorn och språket.

Metallspråken i Schorre -linjen av metakompilatorer är funktionella programmeringsspråk som använder grammatik från top -down som analyserar syntaxekvationer med inbäddade utmatningskonstruktioner.

En syntaxekvation: 

<name> = <body>;

är en sammanställd testfunktion som returnerar framgång eller misslyckande . <namn> är funktionsnamnet. <body> är en form av logiskt uttryck som består av tester som kan grupperas, ha alternativ och produktioner. Ett test är som en bool på andra språk, framgång är sann och misslyckande är falsk .

Att definiera ett programmeringsspråk analytiskt uppifrån och ner är naturligt. Ett program kan till exempel definieras som: 

 program = $declaration;

Definiera ett program som en sekvens av noll eller fler deklarationer.

På Schorre META X -språken finns en drivande regel. Programregeln ovan är ett exempel på en körregel. Regeln Programmet är en provfunktion som kräver förklaring en prov regel att avkastningen framgång eller misslyckande . $ Loop -operatören ringer upprepade gånger till deklarationen tills fel återkommer. $ -Operatören är alltid framgångsrik, även när det finns nolldeklaration. Ovanstående program skulle alltid ge framgång. (I CWIC kan ett långt misslyckande kringgå deklaration. Ett långt misslyckande är en del av CWIC: s backtracking-system)

Teckenuppsättningarna för dessa tidiga kompilatorer var begränsade. Tecknet / användes för den alternativa (eller) operatören. "A eller B" skrivs som A / B. Parenteser () används för gruppering. 

A (B / C)

Beskriver en konstruktion av A följt av B eller C. Som ett booleskt uttryck skulle det vara 

A and (B or C)

En sekvens XY har en underförstådd X- och Y -betydelse. () Är att gruppera och / den eller operatören. Utvärderingsordningen är alltid från vänster till höger eftersom en inmatningsteckensekvens specificeras genom ordning av testerna.

Speciella operatörsord vars första tecken är ett "." används för tydlighetens skull. .EMPTY används som det sista alternativet när ingen tidigare alternativ behöver finnas. 

X (A / B / .EMPTY)

Indikerar att X valfritt följs av A eller B. Detta är en specifik egenskap hos dessa metallspråk som är programmeringsspråk. Backtracking undviks av ovanstående. Andra kompilatorkonstruktorsystem kan ha deklarerat de tre möjliga sekvenserna och lämnat det upp till parsern att räkna ut det.

Egenskaperna för metaprogrammeringsmetallspråken ovan är gemensamma för alla Schorre -metakompilatorer och de som härrör från dem.

META I

META I var en handkompilerad metakompilator som användes för att sammanställa META II. Lite annat är känt om META I förutom att den första sammanställningen av META II gav nästan identisk kod till den för den handkodade META I -kompilatorn.

META II

Huvudartikel: META II

Varje regel består valfritt av tester, operatörer och produktioner. En regel försöker matcha någon del av inmatningsprogrammets källkaraktärström som returnerar framgång eller misslyckande. Vid framgång går inmatningen över matchade tecken. Vid fel är ingången inte avancerad.

Utgångsproduktioner producerade en form av sammansättningskod direkt från en syntaxregel.

TRÄMETA

Huvudartikel: TREE-META

TREE-META introducerade trädbyggnadsoperatörer : < nodnamn > och [ < nummer > ] som flyttar produktionen omvandlas till ojämna regler. Trädbyggnadsoperatörerna användes i grammatikreglerna som direkt omvandlade ingången till ett abstrakt syntaxträd . Ojämna regler är också testfunktioner som matchade trädmönster. Ojämna regler anropas från en grammatikregel när ett abstrakt syntaxträd ska omvandlas till utdatakod. Byggandet av ett abstrakt syntaxträd och ojämna regler gjorde det möjligt att utföra lokala optimeringar genom att analysera parseträdet.

Att flytta produktioner till de ojämna reglerna gjorde en tydlig åtskillnad mellan grammatikanalys och kodproduktion. Detta gjorde programmeringen lättare att läsa och förstå.

CWIC

1968-1970 utvecklade Erwin Book, Dewey Val Schorre och Steven J. Sherman CWIC. (Compiler for Writing and Implementing Compilers) på System Development Corporation Charles Babbage Institute Center for the History of Information Technology (Box 12, folder 21) ,

CWIC är ett kompilatorutvecklingssystem som består av tre specialanpassade, domänspecifika språk, var och en avsedd att möjliggöra beskrivning av vissa aspekter av översättning på ett enkelt sätt. Syntaxspråket används för att beskriva igenkänning av källtext och konstruktionen från den till en mellanliggande trädstruktur . Generatorspråket används för att beskriva transformationen av trädet till lämpligt objektspråk.

Syntaxspråket följer Dewey Val Schorres tidigare rad metakompilatorer. Det liknar mest TREE-META som har trädbyggande operatörer på syntaxspråket. De ojämna reglerna för TREE-META utvidgas till att fungera med det objektbaserade generatorns språk baserat på LISP 2 .

CWIC innehåller tre språk:

  • Syntax : Omvandlar källprogrammets ingång till liststrukturer med hjälp av grammatikomvandlingsformel. En analyserad uttrycksstruktur skickas till en generator genom placering av ett generatoranrop i en regel. Ett träd representeras av en lista vars första element är ett nodobjekt. Språket har operatörer, < och > , speciellt för att göra listor. Dubbelpunkten : operator används för att skapa nodobjekt. : ADD skapar en ADD -nod. Utropet ! operator kombinerar ett antal analyserade poster med en nod för att skapa ett träd . Träd som skapas av syntaxregler skickas till generatorfunktioner, vilket leder till framgång eller misslyckande. Syntaxspråket ligger mycket nära TREE-META. Båda använder ett kolon för att skapa en nod. CWIC s träd byggnad utrop! <Nummer> fungerar på samma sätt som träd META s [<nummer>].
  • Generator : en namngiven serie omvandlingsregler, var och en bestående av en ojämn, mönstermatchande, regel. och en produktion som är skriven på ett LISP 2 -liknande språk. översättningen var till IBM 360 -kod för binär maskin. Andra funktioner i generatorns språk generaliserade utdata.
  • MOL-360 : ett oberoende implementeringsspråk för mellannivå för IBM System/360-datorfamiljen som utvecklades 1968 och används för att skriva det underliggande supportbiblioteket.

Generators språk

Generators Language hade semantik som liknade Lisp . Den parse träd var tänkt som en rekursiv lista. Den allmänna formen för en Generator Language -funktion är: 

  function-name(first-unparse_rule) => first-production_code_generator
           (second-unparse_rule) => second-production_code_generator
           (third-unparse_rule) => third-production_code_generator
               ...

Koden för att behandla ett givet träd inkluderade funktionerna i ett programmeringsspråk för allmänna ändamål, plus en form: <stuff>, som skulle avge (saker) till utdatafilen. Ett generatoranrop kan användas i unparse_rule. Generatorn överförs elementet av unparse_rule -mönster där den placeras och dess returvärden anges i (). Till exempel: 

  expr_gen(ADD[expr_gen(x),expr_gen(y)]) =>
                                <AR + (x*16)+y;>
                                releasereg(y);
                                return x;
               (SUB[expr_gen(x),expr_gen(y)])=>
                                <SR + (x*16)+y;>
                                releasereg(y);
                                return x;
               (MUL[expr_gen(x),expr_gen(y)])=>
                              .
                              .
                              .
               (x)=>     r1 = getreg();
                            load(r1, x);
                            return r1;
...

Det vill säga, om parse trädet ser ut (ADD [<something1>, <something2>]), expr_gen (x) skulle kallas med <something1> och retur x. En variabel i unparse -regeln är en lokal variabel som kan användas i production_code_generator. expr_gen (y) anropas med <something2> och returnerar y. Här är ett generatoranrop i en ojämn regel skickas elementet i den position det upptar. Förhoppningsvis kommer ovanstående x och y att vara register vid retur. De sista transformeringarna är avsedda att ladda en atom i ett register och returnera registret. Den första produktionen skulle användas för att generera 360 "AR" -instruktionen (Lägg till register) med lämpliga värden i allmänna register. Ovanstående exempel är bara en del av en generator. Varje generatoruttryck utvärderas till ett värde som sedan kan bearbetas vidare. Den sista omvandlingen kunde lika gärna ha skrivits som: 

               (x)=>     return load(getreg(), x);

I det här fallet returnerar load sin första parameter, registret returneras av getreg (). funktioner ladda och getreg är andra CWIC -generatorer.

CWIC tog upp domänspecifika språk innan termen domänspecifikt språk fanns

Från författarna till CWIC:

"En metakompilator hjälper uppgiften att bygga kompilatorer genom att automatisera dess icke-kreativa aspekter, de aspekter som är desamma oavsett vilket språk som den producerade kompilatorn ska översätta. Detta möjliggör utformning av språk som är lämpliga för specifikationen av en Det minskar kostnaderna för att producera processorer för sådana språk till en punkt där det blir ekonomiskt möjligt att börja lösa ett problem med språkdesign. "

Exempel

Se även: Jämförelse av parsergeneratorer

Se även

Referenser och anteckningar

Vidare läsning

externa länkar