Lexicale analyse en Fortran

Het ASF+SDF framework maakt gebruik van de SGLR parsing techniek (scannerless, generalized left-to-right rightmost-derivation parsing). Scan-nerless wil zeggen dat een sglr parser geen gebruik maakt van een aparte lexical analyzer die een tekst alvast in hapklare tokens aan de parser aanle-vert; de sglr parser verwerkt zelf elke letter en elk symbool van de invoertekst en bouwt op basis van SDF regels een parsetree waarin ook de gehele invoer-tekst is opgenomen, inclusief whitespace en commentaar. Dit gaat ten koste van snelheid maar voor coderenovatie en code-analyses is dit zeer geschikt omdat er zelfs op commentaar-niveau analyses of transformaties kunnen worden gedaan en de de originele broncode weer letterlijk uit de parsetree kan worden gehaald.

De sglr parser is scannerless, maar in de onderliggende SDF definitie van de taal wordt wel onderscheid gemaakt in lexicale grammaticaregels (verge-lijkbaar met het scanner-deel van een parser) en de bekende context-vrije grammaticaregels. De contextvrije grammaticaregels kennen een bijzonde-re soort (nonterminal) genaamd LAYOUT, die impliciet tussen elke term in een productieregel wordt opgenomen. LAYOUT is hierbij de lexicale defini-tie van alle witruimte tussen taalelementen in een tekst. Voor de meeste talen is de layout-definitie zoals die wordt meegeleverd in de SDF module

’basic/whitespace’ voldoende:

lexical syntax

[\ \t\n] -> LAYOUT %% space, tab and newline are whitespace context-free restrictions

LAYOUT? -/- [\ \t\n] %% and are treated as a whole Voor regel-georienteerde talen als Fortran kan het nodig zijn om hiervan af te wijken omdat er onderscheid moet kunnen worden gemaakt tussen de verschillende Fortran programmaregels. Het newline-token wordt dan opgenomen in de grammaticaregels. Ook de kolom-indeling die (fixed source form) Fortran kent, met de speciale betekenis van posities 1 en 6, vormen een probleem bij de lexicale syntaxdefinitie omdat er geen mogelijkheid is om kolomposities als voorwaarde of (lexicaal) element aan te geven.

Nog een aspect dat Fortran een lastige taal voor scanners/parsers maakt is dat spaties eigenlijk helemaal niet significant zijn, behalve als ze in strings staan. Een populair voorbeeld, beschreven in [1] luidt ongeveer als volgt:

DO 5 I = 1,25 ! DO-loop with label 5 and I running 1-25 DO5I = 1.25 ! assignment of value 1.25 to variable DO5I DO5I = 1,25 ! DO-loop with label 5 and I running 1-25 DO 5 I = 1.25 ! assignment of value 1.25 to variable DO5I D O 5 I = 1 . 2 5 ! assignment of value 1.25 to variable DO5I D O 5 I = 1 , 2 5 ! DO-loop with label 5 and I running 1-25 Pas op het moment dat de komma is gelezen kan de parser beslissen dat het hier om een DO-loop gaat en niet om een assignment statement. De SGLR parser heeft hier geen problemen mee omdat deze redelijk ver vooruit kan kijken (lookahead theoretisch onbeperkt). De laatste twee regels zijn vrij vergezocht maar geldige Fortran fixed source form code en lastiger in SDF regels te vatten. In het free source form formaat is het gelukkig niet toegestaan om willekeurig spaties tussen ’tokens’ te plaatsen al accepteren veel compilers dit nog wel.

In par. 5.1.3 is beschreven welke oplossingen hiervoor gevonden zijn.

Hoofdstuk 4

Onderzoeksmethode

Het maken van een Fortran SDF definitie kunnen we vergelijken met een software ontwikkelingstraject met de bijbehorende globale aanpak:

1. Requirements analyse. Wat zijn de eisen aan het eindproduct?

2. Constructie en implementatie.

3. Testen en validatie

De onderzoeksvraag richt zich op de kwaliteit en bruikbaarheid van een Fortran grammatica die eerst nog dient te worden gemaakt. De kwaliteit hangt samen met de requirements die aan het product gesteld worden. De requirements waren in eerste instantie kort en duidelijk: zoveel mogelijk Fortran code kunnen parsen en daar analyses op kunnen doen. Bij aanvang van het project was nog onduidelijk of Fortran als taal niet te complex was voor de Meta-Environment; dat er nog geen SDF grammatica beschikbaar was voor zo’n oude taal was al opmerkelijk.

Over het proces van grammatica-extractie van andere talen zoals Cobol is literatuur beschikbaar In het artikel Semi-automatic Grammar Recovery [6]

beschrijven Ralf L¨ammel en Chris Verhoef een aanpak om semi-automatisch een grammatica uit beschikbare bronnen te extraheren. De beschreven aan-pak lijkt bij uitstek geschikt om in dit project toe te passen. De volgende stappen worden genoemd:

1. Raw grammar extraction from a language reference, a compiler or ano-ther artifact. Hierbij wordt bij language reference uiteraard direct aan

de Fortran standaard documenten gedacht.

2. Resolution of static errors such as unconnected nonterminals, also cal-led sort names, if the grammar is extracted from a nonexecutable sour-ce.

De Meta-Environment levert waaarschuwingen bij ongedefinieerde of ongebruikte soortnamen. Parse errors en dit soort warnings moeten worden verholpen.

3. Extraction or definition of lexical syntax

Het is interessant dat dit apart genoemd wordt, en voor Fortran is dit ook een lastig probleem (zie 3.3).

4. Test-driven correction and completion of the raw grammar if necessary Pas als zowel het lexicale als contextvrije deel er is kan er worden getest met het parsen van bestaande en nieuwe Fortran testcode. Een beschikbare Fortran compiler kan in twijfelgevallen uitsluitsel geven over de geldigheid van code. GFortran (Gnu Fortran) is een bekende open source Fortran compiler.

5. Beautification

Er dient een nette overzichtelijke layout voor de SDF code te worden gekozen waarbij de ISO standaard een leidraad kan zijn.

6. Modularization

Is de structuur van Fortran zodanig dat het in relatief onafhankelijke losgekoppelde modulen kan worden ingedeeld? Dit maakt eventuele herbruikbaarheid van diverse modulen mogelijk en maakt de taal ook overzichtelijker.

7. Disambiguation if necessary

De ASF+SDF Meta-Environment kan zonodig omgaan met ambi-gu¨ıteiten in een taaldefinitie. De vraag is of het bij Fortran nodig is om dubbelzinnigheden in de taal toe te laten.

8. Generation of a browsable version of the grammar if needed

Een grammatica in Html-vorm met elke nonterminals als links werkt zeer prettig en scheelt zoeken en scrollen. Het is niet noodzakelijk voor dit project.

9. Adaptation of the grammar for the intended purpose (e.g., renovati-on).

Aangezien de use-case voor de grammatica niet bekend is zal dit door

toekomstige gebruikers van de Meta-Environment worden gedaan zo-dra deze een Fortran renovatie-, transformatie- of analyse-taak dienen te volbrengen.

Deze aanpak zal zoveel mogelijk gevolgd worden.

Punt twee en vier in dit stappenplan voorzien reeds in een basale vorm van testen, al is nog niet duidelijk wat de testcriteria hierbij zijn. Voor de Fortran extractie casus is de bruikbaarheid in de Meta-Environment een belangrijk criterium; met ASF regels dient Fortran code te kunnen worden geanalyseerd. Dit zal dan ook aangetoond moeten worden. Met de ISO standaard in de hand als enige alom erkende correcte Fortran definitie zal worden getracht om de SDF definitie zoveel mogelijk op de ISO standaard af te stemmen in de hoop dat daarmee de kwaliteit van de grammatica ook gegarandeerd is. Met behulp van een rule coverage meting zal worden bepaald of de gebruikte Fortran testcode wel voldoende gevarieerd is om alle aspecten van de Fortran grammatica te kunnen testen op ’parseerbaarheid’.

Hoofdstuk 5

Onderzoek

Zoals in hoofdstuk 4 vermeld zullen eerst de grammar recovery stappen moeten worden gevolgd voordat er iets met de grammatica gedaan kan wor-den. Elke stap wordt beschreven. Daarna volgt een test met gebruik van ASF transformatieregels en een coverage analyse van de Fortran code die als testdata voor de grammatica is gebruikt.

5.1 Grammar Recovery

In hoofdstuk 4 is het grammar recovery proces in negen stappen beschre-ven. De eerste zes worden in de volgende hoofdstukken uitgewerkt. Stap 7, disambiguation bleek vooral bij de lexicale definitie (stap 3) en de daarop-volgende testfase al nodig te zijn en is niet apart beschreven, ook al heeft het zeer veel tijd gekost om ambigu¨ıteiten in de grammatica op te lossen.

Stap 9, het aanpassen van de grammatica voor een specifieke use-case blijft ook buiten beschouwing aangezien dat buiten de scope van de ontwikkeling van de baseline grammar ligt.