Choose an application

• Reference Manager
• EndNote
• RefWorks (Direct export to RefWorks)

Designers van programmeertalen die een taal willen voorzien van een typesysteem, dienen hiervoor twee artefacten op te stellen. Eerst en vooral moeten ze instaan voor de specificatie van het typesysteem. Daarnaast moeten ze een typechecker implementeren die gebruikt zal worden in de compiler van de programmeertaal. Het is lastig om beide artefacten aan te maken en te bestuderen maar vooral om er voor te zorgen dat ze op elkaar afgestemd blijven tijdens dit proces. Hierbij kunnen fouten en ongewenste eigenschappen geïntroduceerd worden. Het doel van deze thesis is om te onderzoeken hoe men automatisch van de specificatie van een typesysteem naar een typechecker kan gaan. Zo kan een programmeertaalde- signer zich focussen op het ontwerp van het typesysteem zelf, zal hij minder werklast ervaren en zal hij snel prototypes kunnen ontwikkelen van typesystemen. Om tot deze automatische vertaling te komen, zijn in dit werk twee typesystemen onderzocht: Simply Typed Lambda Calculus (STLC) en het typesysteem dat ge- bruikt wordt voor de decompilatie van MinX naar MinC. De typeringsregels van dit laatste typesysteem kunnen niet automatisch worden vertaald omdat ze een expliciete transitiviteitsregel bevatten. Daarom zijn de typeringsregels eerst manueel omgevormd naar andere regels die wel automatisch vertaald kunnen worden. De juistheid van deze manuele transformatie werd wiskundig bewezen. Vervolgens is een algoritme gedefinieerd om de typeringsregels van een typesysteem automatisch te ver- talen zodanig dat de transitiviteitsregel verwijderd wordt. Verder is een programma ontwikkeld dat gebruik maakt van dit algoritme om een automatische vertaling naar een typechecker te realiseren. Het algoritme is toegepast op enkele typesystemen en de resultaten hiervan zijn correct. Verder onderzoek is nodig om na te gaan of het algoritme op ieder typesysteem kan worden toegepast en om hiervan het bewijs te leveren. De resultaten van deze thesis openen alvast perspectieven om ontwikkelaars van programmeertalen in de toekomst een automatische tool aan te reiken die hen kan ondersteunen in hun opdracht.

Choose an application

• Reference Manager
• EndNote
• RefWorks (Direct export to RefWorks)

Debuggen in talen met lazy evaluatie is moeilijk doordat de volgorde van uitvoering niet altijd overeenkomt met de verwachtingen van de gebruiker. Declaratieve debuggers lossen dit probleem op door programma’s om te zetten naar beslissingsdiagrammen. De gebruiker kan dit diagram doorlopen door vragen te beantwoorden en op deze manier de locatie van de bug vinden. Deze debuggers hebben echter een aantal nadelen. Ten eerste kunnen de gestelde vragen zeer complex worden. Ten tweede zijn deze debuggers geheugen- of tijdsintensief voor grote programma’s. In deze thesis wordt een nieuwe debug methode onderzocht dat we Property Based Debugging (PBD) noemen. Hierbij probeert de gebruiker een beschrijving te geven van geobserveerde bugs. Dit gebeurt in de vorm van eigenschappen, gelijkaardig aan hoe in Property Based Testing programma eigenschappen worden gespecificeerd om bugs op voorhand te vinden. Vervolgens zal in PBD de debugger automatisch op zoek gaan naar de bug en informatie over de bug rapporteren. In deze thesis wordt een implementatie van PBD in de KU Leuven Haskell Compiler (KHC) voorgesteld. Ten slotte wordt aan de hand van een case studie gekeken in welke mate deze implementatie een verbetering teweeg brengt ten opzichte van voorgaande debug technieken.

Choose an application

• Reference Manager
• EndNote
• RefWorks (Direct export to RefWorks)

Choose an application

• Reference Manager
• EndNote
• RefWorks (Direct export to RefWorks)

Smartphones en de bijhorende applicaties zijn alomtegenwoordig. De beperkte opslagcapaciteit en bandbreedte maakt dat de applicatiegrootte een belangrijke factor is voor veel smartphonegebruikers. Tegelijk moeten de applicaties voldoende snel werken. Appontwikkelaars maken handig gebruik van reeds bestaande code die in de vorm van bibliotheken aan een applicatie wordt toegevoegd. Die bibliotheken bevatten echter heel wat ongebruikte extra code die juist bijdraagt aan de applicatiegrootte. De bytecodeoptimalisators ProGuard en R8 bieden een oplossing om die overbodige code te verwijderen. Door de JVM-bytecode van applicaties te analyseren, zijn ze in staat om de applicatie te verkleinen en enigszins te versnellen met behoud van de originele applicatielogica. Veel applicaties voor het besturingssysteem Android worden tegenwoordig in Kotlin geschreven. Daarbij gebruiken appontwikkelaars vaak bibliotheken die het gebruik van lambdafuncties stimuleren. Een lambdafunctie in Kotlin wordt in JVM-bytecode voorgesteld door een aparte lambdaklasse. Die representatie zorgt echter voor grotere applicaties. R8 bevat al een optimalisatietechniek die lambdaklasses tot lambdagroepen samenvoegt: een klasse met daarin verschillende lambda-implementaties. Die techniek heet lambda merging. ProGuard daarentegen mist die optimalisatie. Bovendien ontbreekt er in de literatuur een beschrijving van deze optimalisatietechniek. Wat de impact is van lambda merging op de applicatiegrootte en de performantie van lambdafuncties in Kotlin is ook niet geweten. Deze masterproef introduceert een aanpak om lambda merging te implementeren. Een evaluatie van de implementatie van die aanpak in ProGuard toont aan dat applicaties gemiddeld 12~\% kleiner worden dankzij lambda merging. Bovendien blijven de extra vertragingstijden bij het initialiseren en oproepen van de lambdafuncties beperkt tot de orde van nanoseconden. Op het vlak van reductie in codegrootte presteert deze implementatie in combinatie met de bestaande optimalisaties in ProGuard beter dan de classfile-modus van R8, maar slechter dan de dex-modus van R8. Die laatste is immers de modus waarin lambda merging wordt toegepast. Wat de performantie betreft, werken de lambdagroepen van R8 over het algemeen sneller, maar voor lambdafuncties zonder vrije variabelen en met een beperkt aantal argumenten lijkt R8 juist slechter te presteren.

Choose an application

• Reference Manager
• EndNote
• RefWorks (Direct export to RefWorks)

De integratie van functionele concepten in imperatieve programmeertalen is een groeiende trend. Java 8 voegde Streams, Optionals en lambda-expressies toe aan Java. Deze concepten zijn geïnspireerd op concepten uit Haskell. Streams bieden gelijkaardige operatoren aan als de lijsten in Haskell. Optionals bieden dezelfde functionaliteit als de Maybe Monad uit Haskell. Deze functionele concepten bieden in theorie enkele voordelen: ze maken code compacter en duidelijker. Om dit te testen passen we deze concepten toe in een case study waarbij for-lussen vervangen worden door Stream-operaties. Om deze vervanging te kunnen uitvoeren, hebben we soms andere functionele concepten nodig. Hiervoor halen we de nodige inspiratie uit Haskell. De Monoid krijgt een volledige integratie in Java 8. Concepten als de Functor en Applicatieve Functor kunnen niet volledig geïntegreerd worden. De voornaamste oorzaak is het ontbreken van typeconstructoren in Java. We lossen dit op met individuele methodes die wel niet de generaliteit hebben die Haskell wel heeft. Niet alle for-lussen worden vervangen: Het combineren van Stream-operaties stuit hier op zijn grenzen. Vaak is dergelijke code van mindere kwaliteit en niet voldoende opgedeeld. Ook in Haskell ligt de voorkeur op meerdere kleinere functies dan één grote functie. Deze voorkeur zien we terug bij Streams. Een analyse van de vervanging leert ons dat de code met Streams minder codelijnen bevat. Wel zijn er meer karakters in de code. Dit is vooral te wijten aan de overhead van de Streams API en externe libraries.