Software Engineering

Finished Thesis Topics

We are look­ing for­ward to work­ing with you on your the­sis pro­ject (in Ger­man or Eng­lish)! Our group of­fers a range of open the­sis top­ics in the gen­eral area of soft­ware en­gi­neer­ing or pro­gram­ming lan­guages. We also wel­come your own ideas, es­pe­cially if they are in scope of our re­search top­ics.

If you are in­ter­ested in pur­su­ing a the­sis with our group, please send us an email with the fol­low­ing in­for­ma­tion:

  • a brief de­scrip­tion of the kind of work you are in­ter­ested in (e.g. more the­o­ret­i­cal, more prac­ti­cal, a pro­gram­ming task, ...)
  • your level of knowl­edge of the the­ory or im­ple­men­ta­tion of pro­gram­ming lan­guages (if any)
  • a cur­rent tran­script of your grades
  • po­ten­tially rel­e­vant skills you ac­quired out­side of uni­ver­sity

List of al­ready fin­ished the­sis top­ics

Elis­a­beth Fritze (MSc)

A Mod­ern Im­ple­men­ta­tion of Cut Elim­i­na­tion for Clas­si­cal Se­quent Cal­cu­lus

The sym­met­ri­cal prop­er­ties of the se­quent cal­cu­lus make it an in­ter­est­ing base for func­tional pro­gram­ming lan­guages. In con­trast to the preva­lent base lambda cal­cu­lus, it al­lows for an equiv­a­lent treat­ment of terms pro­duc­ing in­for­ma­tion and eval­u­a­tion con­texts. In this the­sis, we have con­structed and im­ple­mented a term lan­guage for the se­quent cal­cu­lus, along with its cut-free frag­ment. We fur­ther pre­sent a nor­mal­iza­tion func­tion that eval­u­ates state­ments to their cut-free form, uti­liz­ing cut elim­i­na­tion and hered­i­tary sub­sti­tu­tion. Thereby, it lends it­self as a com­piler in­ter­me­di­ate lan­guage, shift­ing com­pu­ta­tion from run­time to com­pile-time, and op­ti­miz­ing pro­gram ex­e­cu­tion.

Read more ...
Lena Käufel (BSc)

Prop­erty Test­ing in Ef­fekt

Test­ing is one of the most im­por­tant meth­ods for en­sur­ing soft­ware qual­ity. How­ever, tra­di­tional ex­am­ple-based test­ing meth­ods have in­her­ent lim­i­ta­tions: they are re­stricted to eval­u­at­ing in­di­vid­ual sce­nar­ios, yet they are often used to jus­tify broader claims than these sce­nar­ios can sup­port.

Read more ...
Lars Seif (BSc)

Kom­pilierung von Ef­fek­thandlern mit In­ter­ak­tion­skom­bi­na­toren

In dieser Bach­e­lo­rar­beit wird beschrieben wie Bend, eine Pro­gram­mier­sprache, die auf In­ter­ak­tion­skom­bi­na­toren basiert und noch in En­twick­lung ist, als Back­end des Ef­fekt Kom­pilier­ers hinzugefügt wird. Bend kom­piliert zu HVM, was für Higher-or­der Vir­tual Mashine steht. HVM im­ple­men­tiert die von La­font [5] ent­wor­fe­nen In­ter­ak­tion­skom­bi­na­toren. Bend kann einige Lambda-Terme in von Levy [7] definierter op­ti­maler Zeit berech­nen und sehr le­icht mehrere Berech­nun­gen par­al­lel durchführen. De­shalb hof­fen wir mit Bend als Back­end die Laufzeit von Ef­fekt in eini­gen Pro­gram­men stark zu re­duzieren.

Read more ...
Mat­tis Böckle (BSc)

Com­pil­ing clas­si­cal se­quent cal­cu­lus to LLVM

This the­sis aims to pro­vide a way to trans­late clas­si­cal se­quent cal­cu­lus to the LLVM in­ter­me­di­ate rep­re­sen­ta­tion to uti­lize the LLVM tool­chain and achieve greater per­for­mance than com­pil­ing di­rectly to ma­chine code. We pro­vide ex­am­ples of how this trans­la­tion works, what the re­sult­ing op­ti­mized ver­sion looks like and how and why we im­ple­mented a cus­tom mem­ory al­lo­cater to suit our needs. We show how to eval­u­ate the re­sult­ing pro­grams and how we test the va­lid­ity of the trans­la­tion. Fi­nally we bench­mark our ap­proach against other pro­gram­ming lan­guages and com­pare the re­sult­ing per­for­mance.

Read more ...
Jonas Kräher (BSc)

Soft­ware Trans­ac­tional Mem­ory in Ef­fekt

Con­cur­rent pro­grams are widely used in prac­tice, but no­to­ri­ously dif­fi­cult to get right, par­tic­u­larly when deal­ing with the lock­ing and syn­chro­niza­tion of shared mem­ory be­tween threads. How­ever, en­sur­ing cor­rect­ness be­comes even more chal­leng­ing when in­di­vid­ual com­po­nents, which may func­tion cor­rectly in iso­la­tion, in­ter­act with each other. Soft­ware Trans­ac­tional Mem­ory of­fers a so­lu­tion by ab­stract­ing over the low-level de­tails of con­cur­rent pro­gram­ming, pro­vid­ing atomic blocks that en­able mod­u­lar com­posi­bil­ity of trans­ac­tions.

Read more ...
Sina Schäfer (BSc)

Prob­a­bilis­tic Ef­fekt

In­fer­ence pro­gram­ming - the adap­ta­tion of in­fer­ence al­go­rithms to a par­tic­u­lar model or prob­lem - is dif­fi­cult in lan­guages that do not deal with side ef­fects or do not han­dle side ef­fects prop­erly due to their na­ture of re­ly­ing on ef­fect­ful com­pu­ta­tion. In func­tional pro­gram­ming, monad trans­form­ers are the most com­mon ap­proach to con­trol side ef­fects. How­ever, this makes it dif­fi­cult to cus­tomise such al­go­rithms. Ef­fects and ef­fect han­dlers on the other hand in­tro­duce an­other pos­si­bil­ity to deal with pro­gram­ma­ble in­fer­ence. This the­sis will demon­strates this idea by de­vel­op­ing three in­fer­ence pat­terns (Me­trop­o­lis-Hast­ings, slice sam­pling and re­jec­tion sam­pling) using the lan­guage Ef­fekt. The re­sult is a more user-friendly way to adapt and com­bine parts of these al­go­rithms

Read more ...
Max­i­m­il­ian Marschall (BSc)

Is Ef­fekt Fast Yet

Alle Pro­gram­mier­sprachen be­sitzen eine gemein­same Schnittmenge der grundle­gen­den Ab­strak­tio­nen. Durch einen Kom­piler oder In­ter­preter wer­den die Ab­strak­tio­nen in Maschi­nen­code umge­setzt und dann aus­geführt. Je besser diese Um­set­zung op­ti­miert ist, desto per­for­man­ter ist die Ausführung des Pro­grammes. Im Paper Are-We-Fast-Yet [ 5 ] wer­den 9 Mi­crobench­marks en­twick­elt, welche in mod­erat kom­plexen Pro­gram­men jew­eils bes­timmte Bere­iche dieser Core Lan­guage testen. Die Bench­marks wer­den in ver­schiedene Pro­gram­mier­sprachen im­ple­men­tiert und die Ausführung auf Zeit gemessen. An­hand der Ergeb­nisse lässt sich eine generelle Aus­sage über die Per­for­manz einer Pro­gram­mier­sprache, beziehungsweise Kom­pil­ers/In­ter­preters machen.

Read more ...
Matthias Dunkel (BSc)

Re­ac­tive: De­sign and Im­ple­men­ta­tion of a syn­chro­nous re­ac­tive pro­gram­ming li­brary in Ef­fekt

Re­ac­tive sys­tems are an im­por­tant part of every­day pro­gram­ming. Still, the im­ple­men­ta­tions of such re­ac­tive sys­tems dif­fer hugely, which has a major im­pact on the style and re­li­a­bil­ity of re­ac­tive pro­grams. The main ap­proach to im­ple­ment­ing re­ac­tiv­ity and par­al­lelism in the in­dus­try is to use multi-thread­ing. This ap­proach often leads to non-de­ter­min­is­tic be­hav­ior. Ad­di­tion­ally, pro­gram­ming lan­guages often need extra im­ple­men­ta­tions for re­ac­tiv­ity and par­al­lelism to sup­port multi-thread­ing. Lan­guages such as Ef­fekt erad­i­cate the need for ad­di­tional re­ac­tive sys­tem lan­guage sup­port, by im­ple­ment­ing al­ge­braic ef­fects. With al­ge­braic ef­fects, it is pos­si­ble to im­ple­ment a vast amount of pro­grams, in­clud­ing re­ac­tive sys­tems. In this work, we pre­sent Re­ac­tive, a li­brary for the pro­gram­ming lan­guage Ef­fekt. Re­ac­tive uses al­ge­braic ef­fects to im­ple­ment re­ac­tiv­ity and par­al­lelism in di­rect style. The abil­ity to write pro­grams in di­rect style leads to more read­able code, as it ap­pears to be se­quen­tial, while the con­trol flow is han­dled with al­ge­braic ef­fects. Re­ac­tive de­fines a syn­chro­nous ex­e­cu­tion model, by in­ter­leav­ing wait­ing parts of the pro­gram. The syn­chro­nous ap­proach of the li­brary makes de­ci­sions over the ex­e­cu­tion flow of the pro­gram de­ter­min­is­tic. Par­al­lelism and re­ac­tiv­ity are de­cou­pled by using dif­fer­ent ef­fects and han­dlers. With sched­ulers, Re­ac­tive cre­ates the abil­ity to run parts of a pro­gram in par­al­lel. Re­ac­tive im­ple­ments dif­fer­ent sched­ulers, which han­dle the con­trol flow of the pro­gram by en­forc­ing rules. Such rules can be the ter­mi­na­tion of parts of the pro­gram when an­other has al­ready stopped. The await­ing of an event is done by polling an en­vi­ron­ment in a busy wait loop, which can be in­ter­leaved with other parts of the pro­gram. Ad­di­tional to the Ef­fekt im­ple­men­ta­tion, this the­sis im­ple­ments the abil­ity to wait for JavaScript events in­side the Ef­fekt lan­guage.

Read more ...
Serkan Muhcu (MSc)

Mu­ta­ble State in a Lan­guage with Ef­fect Han­dlers

Ef­fekt is a func­tional pro­gram­ming lan­guage de­vel­oped for re­search on al­ge­braic ef­fects and han­dlers. Aside from al­ge­braic han­dlers, Ef­fekt also fea­tures side ef­fects in form of mu­ta­ble state using re­gion-based mem­ory man­age­ment. The Ef­fekt com­piler has mul­ti­ple back­ends, one of which tar­gets the LLVM In­ter­me­di­ate Rep­re­sen­ta­tion. The LLVM-IR can be com­piled to an ex­e­cutable file with many op­ti­miza­tion passes on the way. The LLVM back­end of Ef­fekt cov­ers only a sub­set of Ef­fekt’s fea­tures. As part of this the­sis, we ex­tend the LLVM back­end by sup­port for mu­ta­ble state.

Read more ...
Fran­ciszek Piszcz (MSc)

Ab­stract-In­ter­pre­ta­tion-Based Lan­guage Server for Python

Most IDEs for Python de­vel­op­ment fol­low tra­di­tional code analy­sis ap­proaches that are known to work well for sta­t­i­cally-typed lan­guages such as Java or C++. A lot of mod­ern Python code is un­typed, and these con­ser­v­a­tive tools tend to as­sign the “Any” type for vari­ables that do not have ex­plicit type an­no­ta­tions. How­ever, pro­gram­mers are usu­ally able to de­duce types (and often con­crete val­ues) by look­ing at sur­round­ing code and jump­ing through func­tion de­f­i­n­i­tions and call sites.

Read more ...
David Voigt (BSc)

Re­source Fi­nal­iza­tion for Ef­fect Han­dlers

Han­dling re­sources, such as files or net­work sock­ets, in a lan­guage with con­trol (such as ex­cep­tions) safely can be­come dif­fi­cult. We need to make sure that all mem­ory is even­tu­ally freed and all file han­dles and sock­ets are closed; even in the case of an ex­cep­tion.

Read more ...
Lukas Stet­ter (BSc)

In­ter­ak­tive Lehrbücher

Viele der Lehr­ma­te­ri­alien welche wir in der Lehre ver­wen­den beste­hen aus nicht in­ter­ak­tiven Skripten und Foliensätzen. Aber viele In­halte der In­for­matik eignen sich beson­ders gut für eine in­ter­ak­tive Präsen­ta­tion. Durch eine in­ter­ak­tive Präsen­ta­tion können auch sehr ab­strakte In­halte greif­bar und verständlich gemacht wer­den. So wird zum Beispiel häufig auf An­i­ma­tio­nen und in­ter­ak­tive Graphiken zurück­ge­grif­fen, um die Ausführung von Al­go­rith­men zu ve­r­an­schaulichen.

Read more ...
Pavel Karasik (MSc)

Im­prov­ing Error Mes­sages with Al­ge­braic Sub­typ­ing

Good type er­rors are an im­por­tant tool to im­prove pro­gram­mer pro­duc­tiv­ity. Ide­ally, they can help to quickly lo­cal­ize and fix prob­lems and help pro­gram­mers to not only bet­ter un­der­stand the error, but also the un­der­ly­ing pro­gram.

Read more ...
Roman Schulte (MSc)

Sec­ond-class Mod­ules for the Ef­fekt Pro­gram­ming Lan­guage

Ef­fekt is a novel pro­gram­ming lan­guage fea­tur­ing new ways to mod­u­lar­ize soft­ware and struc­ture com­plex con­trol flow. In par­tic­u­lar, it in­cludes lex­i­cal ef­fect han­dlers as well as an ad­vanced type- and ef­fect sys­tem. How­ever, the lan­guage is yet lack­ing a full mod­ule sys­tem.

Read more ...
Tim Neu­mann (BSc)

IDE Sup­port for Lex­i­cal Ef­fects and Han­dlers

Sta­tic type sys­tems help to avoid pro­gram­ming er­rors by in­di­cat­ing to the pro­gram­mer at com­pile time that a value po­ten­tially has a wrong type. This way, un­sup­ported op­er­a­tions (such as di­vid­ing two strings or call­ing a method on a num­ber) are ruled out be­fore the pro­gram is ex­e­cuted.

Read more ...