• No results found

Hj¨alpmedel f¨or Encore i utvecklingsmilj¨oer

N/A
N/A
Protected

Academic year: 2021

Share "Hj¨alpmedel f¨or Encore i utvecklingsmilj¨oer"

Copied!
34
0
0

Loading.... (view fulltext now)

Full text

(1)

Hj ¨alpmedel f ¨or Encore i utvecklingsmilj ¨oer

Filip Bj ¨orklund

Christoffer Gustafsson Valter G ˚adin

Andreas Olofsson

Civilingenj ¨orsprogrammet i informationsteknologi

(2)

Institutionen f ¨or informationsteknologi

Bes ¨oksadress:

ITC, Polacksbacken L ¨agerhyddsv ¨agen 2

Postadress:

Box 337 751 05 Uppsala

Hemsida:

http:/www.it.uu.se

Hj ¨alpmedel f ¨ or Encore i utvecklingsmilj ¨ oer

Filip Bj ¨orklund

Christoffer Gustafsson Valter G ˚adin

Andreas Olofsson

When writing code in a modern programming language many people expect to have access to certain tools and utilities, called language features, e.g. hover and diagnostics. Hover shows data types and function definitions etc., when the mouse hovers over parts of the code and diagnostics shows error messages.

Encore is a new programming language that is being developed at Uppsala University as a part of a research project called Upscale.

Upscale is a collaboration between various universities within the EU, with the goal of developing new technologies focused on programming that scales over many cores. Currently Encore is missing a lot of the common language features. An implementation would make developing in Encore a more efficient and enjoyable experience. This report will describe the implementation of some language features using the open standard called language server protocol. Implementing all of its features is a large project, as such the focus of the project is developing a base that can be built upon.

The result was a foundation for language features in Encore. The system has a good response time even for large input data, is crash safe and is something that the Encore team can continue to work on. However, we found that the Encore compiler was not built with this project in mind as it lacked certain features, something that can be improved upon.

Handledare: Anne-Kathrin Peters och Bj¨orn Victor Examinator: Bj¨orn Victor

(3)

N¨ar man skriver kod i ett modernt programmeringsspr˚ak f¨orv¨antar man sig att det finns vissa hj¨alpmedel och verktyg, s˚a kallade spr˚akfunktioner, t.ex. hover och diagnostik.

Hovervisar t.ex. datatyper eller funktionsdefinitioner n¨ar man h˚aller muspekaren ¨over ett kodstycke och diagnostik visar fel i koden.

Encore ¨ar ett nytt programmeringsspr˚ak som utvecklas p˚a Uppsala Universitet som ¨ar en del av det gemensamma forskningsprojektet Upscale. Upscale ¨ar ett samarbete mel- lan flera universitet inom EU med m˚alet att utveckla nya tekniker inom programmering som ska skala ¨over m˚anga k¨arnor. Encore saknar i dagsl¨aget st¨od f¨or m˚anga vanliga spr˚akfunktioner. En implementation av dessa spr˚akfunktioner skulle effektivisera ut- veckling i Encore och g¨ora det till en behagligare upplevelse. Denna rapport kommer beskriva implementationen av st¨od f¨or spr˚akfunktioner med hj¨alp av den ¨oppna standar- den language server protocol. Implementation av alla dess funktioner ¨ar ett stort arbete, s˚aledes ¨ar projektets fokus att skapa en grund som kan byggas vidare p˚a.

Resultatet blev en grund f¨or spr˚akfunktioner i Encore. Systemet har bra responstid ¨aven f¨or stora indata, ¨ar v¨al kraschs¨akrat och ¨ar n˚agot som Encore-teamet kan bygga vidare p˚a. Vi fann dock att Encore-kompilatorn inte utformad med detta projekt i ˚atanke d˚a den saknade viss funktionalitet, n˚agot som kan f¨orb¨attras.

(4)

API Application Programming Interface, gr¨anssnitt f¨or kommunikation AST Abstract Syntax Tree, tr¨adrepesentation av programkod

JSON Format f¨or utbyte av data.

LSP Language Server Protocol, en ¨oppen standard f¨or spr˚akfunktioner.

Regulj¨ara Uttryck Notation f¨or att beskriva vissa m¨angder av str¨angar. Kallas ofta regex.

Spr˚akfunktion Hj¨alpmedel i utvecklingsmilj¨o, se sektion 2.2.

Utvecklingsmilj¨o Samlade verktyg f¨or mjukvaruutveckling.

(5)

1 Introduktion 1

2 Bakgrund 1

2.1 Utvecklingsmilj¨o . . . 1

2.2 Spr˚akfunktioner, hj¨alpmedel i utvecklingsmilj¨o . . . 2

2.3 Uppdragsgivare . . . 2

2.4 Programmeringsspr˚aket Encore . . . 5

2.4.1 Actor-modell . . . 5

2.4.2 Data race . . . 5

2.4.3 Skalbarhet . . . 6

2.5 Kompilatorer . . . 6

3 Syfte, m˚al och motivation 7 3.1 Syfte . . . 7

3.2 M˚al . . . 8

3.3 Motivation . . . 8

3.4 Avgr¨ansningar . . . 8

4 Relaterat arbete 9 4.1 Emacs support . . . 9

4.2 CQuery language server . . . 9

5 Metod 10 5.1 Language Server Protocol (LSP) . . . 10

5.2 Visual Studio Code . . . 11

(6)

5.4 Haskell . . . 11

5.5 Git och Github . . . 12

6 Systemstruktur 12 6.1 Utvecklingsmilj¨o och klient . . . 13

6.2 Gr¨anssnittet . . . 13

6.3 Servern . . . 14

7 Krav och utv¨arderingsmetoder 15 8 Implementation 16 8.1 Klient . . . 16

8.2 Server . . . 16

8.3 Gr¨anssnitt . . . 17

8.3.1 Hover . . . 18

8.3.2 Diagnostik . . . 18

9 Utv¨arderingsresultat 18 9.1 Kodkvalitet . . . 19

9.2 Kraschhantering . . . 19

9.3 Responsivitet . . . 19

10 Resultat 20 10.1 Klient . . . 21

10.2 Server . . . 21

10.3 Gr¨anssnitt . . . 21

(7)

12 Slutsatser 23

13 Framtida arbete 23

13.1 Fullst¨andig implementation av LSP . . . 23

13.2 LSP-Klienter . . . 23

13.3 Effektivitet . . . 24

13.4 Separation av server fr˚an kompilator . . . 24

A Specifikationer 27

(8)

1 Introduktion

Den som n˚agon g˚ang programmerat har s¨akert kommit i kontakt med ett flertal av de funktionaliteter och hj¨alpmedel som finns f¨or att underl¨atta denna process, s˚a kallade spr˚akfunktioner, t.ex. hover och diagnostik. Dessa funktioner ¨ar s˚a vanliga att m˚anga idag tar f¨or givet att de alltid ska finnas tillg¨angliga, oavsett vilket spr˚ak de utvecklar i. Om dessa inte finns ¨ar risken stor att eventuella utvecklare v¨aljer bort de spr˚ak som saknar dessa st¨od. Encore som ¨ar ett nytt programmeringsspr˚ak som utvecklas p˚a Upp- sala universitet har just detta problem. D¨arav tillkom detta projekt, vilket har som m˚al att l¨agga till spr˚akfunktioner f¨or Encore.

F¨or att ˚astadkomma detta anv¨ands language server protocol, LSP, vilket ¨ar en standar- diserar som tillhandah˚allandet av spr˚akfunktioner. F¨ordelen med LSP ¨ar att alla verktyg som st¨odjer standarden inte beh¨over separata implementationer f¨or spr˚akfunktionerna.

Detta leder till att fler kan f˚a tillg˚ang till samma hj¨alpmedel och arbetet med kodun- derh˚all och nya implementationer blir mindre.

2 Bakgrund

Utvecklare i moderna programmeringsspr˚ak f¨orv¨antar sig spr˚akfunktioner som automa- tisk kodkomplettering, diagnostik och liknande. Ett spr˚ak som inte st¨odjer detta riske- rar att f˚a problem med att locka nya anv¨andare. Det ¨ar d¨arf¨or intressant att s˚a m˚anga anv¨andare som m¨ojligt har tillg˚ang till ett s˚adant st¨od.

2.1 Utvecklingsmilj ¨ o

En utvecklingsmilj¨o ¨ar ett verktyg som anv¨ands av utvecklare f¨or att underl¨atta och effektivisera deras kodskrivande. Var gr¨ansen mellan en textredigerare och en utveck- lingsmilj¨o g˚ar ¨ar vag. En vanlig definition av en utvecklingsmilj¨o ¨ar att den erbjuder omfattande hj¨alpmedel kring utvecklandet av kod, t.ex. v¨alutbyggd textredigerare, de- bugger och byggverktyg. Exempel p˚a vanliga utvecklingsmilj¨oer ¨ar Emacs [GNU18]

samt Visual Studio Code [Mic18].

(9)

2.2 Spr ˚akfunktioner, hj ¨alpmedel i utvecklingsmilj ¨ o

Spr˚akfunktioner ¨ar ett samlingsord f¨or vissa hj¨alpmedel som en utvecklingsmilj¨o er- bjuder och som underl¨attar vid programmering. De ¨ar inte begr¨ansade till ett visst pro- grammeringsspr˚ak, utan ¨ar generella hj¨alpmedel som finns f¨or flera spr˚ak. N˚agra av de vanligaste spr˚akfunktionerna ¨ar f¨oljande.

• Kodkomplettering ¨ar n¨ar man b¨orjar skriva p˚a ett uttryck och kodredigeraren presenterar m¨ojliga forts¨attningar, vilket illustreras i fig 1.

• Hover ¨ar en funktion som anv¨ands n¨ar muspekaren ¨ar ovanf¨or en variabel, funk- tion eller liknande och relevant information visas, vilket kan ses i fig 2.

• Hoppa till definition anv¨ands om man vill se hur en funktion, klass eller liknande definieras. N¨ar spr˚akfunktionen anv¨ands ¨oppnas relevant fil med mark¨oren p˚a r¨att rad.

• Hitta referenser ¨ar en funktion som anv¨ands f¨or att hitta referenser ¨over ett helt projekt. En snarlik variant av denna funktionen ¨ar n¨ar man skall d¨opa om en vari- abel, samtliga referenser till variabeln kan d˚a d¨opas om samtidigt, detta illustreras i fig 3.

• Diagnostik erbjuder fel och varningar medan man skriver, ofta i form av under- strykningar i olika f¨arger. Ett exempel p˚a diagnostik kan ses i fig 2.

N¨ar man jobbar p˚a ett mindre projekt ¨ar spr˚akfunktioner n˚agot som underl¨attar och ¨ar hj¨alpsamt. Vid ett medelstort eller stort projekt blir spr˚akfunktioner allt viktigare.

2.3 Uppdragsgivare

Encore ¨ar ett forskningsprojekt p˚a Uppsala Universitet och ¨ar en del av Upscale. Upsca- le ¨ar ett samarbete mellan ett antal europeiska universitet, sponsrat av EU, med m˚alet att fr¨amja utveckling och forskning kring many- och mutli-core teknologier. Many-core

¨ar processorer designade f¨or h¨og parallellism med upp till tusentals k¨arnor. Multi-core

¨ar d¨aremot designade f¨or att fungera f¨or b˚ade parallella och seriella program, de har of- tast f¨arre k¨arnor. Upscale har som vision att erbjuda programmeringsspr˚ak som till˚ater utvecklingen av program som enkelt skalar med parallelliseringen tack vare many-core chip, utan att ge upp nuvarande paradigmer och metodiker [UpS17], dvs. hur vi arbetar och t¨anker kring programmering idag. Encores utvecklingsteam har begr¨ansat med tid och resurser vilket inneb¨ar att de tar hj¨alp av t.ex. oss f¨or att implementera mindre akuta delar av Encore.

(10)

Figur 1 Spr˚akfunktionen kodkomplettering anv¨ands p˚a objektet foo. En ruta dyker upp och visar dess publika medlemmar.

Figur 2 Spr˚akfunktionerna diagnostik och hover samarbetar f¨or att visa ett felmedde- lande n¨ar muspekaren h˚alls ¨over den understrukna kodsnutten.

(11)

Figur 3 Spr˚akfunktionen hitta referenser har anv¨ants p˚a metoden foo i klassen Foo.

Rutan under visar de fallen d¨ar metoden anv¨ands. Notera att metoden foo i klassen Bar ignoreras.

(12)

2.4 Programmeringsspr ˚aket Encore

Encore [Et17] ¨ar ett objektorienterat programmeringsspr˚ak under utveckling med in- fluenser b˚ade fr˚an funktionella och imperativa spr˚ak. Det ¨ar ett h¨ogniv˚aspr˚ak och ¨ar d¨armed relativt enkelt att anv¨anda, d˚a mycket av det bakomliggande abstraheras bort.

En h¨og abstraktionsniv˚a inneb¨ar att koden blir mer l¨attf¨orst˚aelig och mindre kunskap kr¨avs om hur datorn fungerar p˚a l˚ag niv˚a. D˚a Encore ¨annu ¨ar i ett tidigt stadie av sin utveckling har det ¨annu inte n˚att en st¨orre publik.

Fokus f¨or Encore ligger p˚a parallellprogrammering och f¨oljer Upscales vision med att utveckla programmeringsspr˚ak som skalar till many-core processorer. Encore ˚astadkommer detta genom att anv¨anda sig av actor-modellen, vilket g¨or det till ett actor-based langu- age.

2.4.1 Actor -modell

Actor-modellen ¨ar inget nytt f¨or Encore, utan har funnits som koncept ¨anda sedan 70- talet [Hew77]. Modellen bygger p˚a sm˚a objekt kallade actors som ¨ar spr˚akets grund- stenar, d¨ar varje actor inneh˚aller en eller flera logiska tr˚adar. Dessa actors ¨ar ganska lika vanliga objekt i objektorienterade spr˚ak, med den stora skillnaden att deras interna tillst˚and, dvs. lokala variabler, ¨ar helt skilda ifr˚an varandra. F¨or att kommunicera med varandra kan de inte skicka data som i andra programmeringsspr˚ak, utan allt sker via asynkrona meddelanden.

N¨ar en actor f˚ar ett meddelande kan den g¨ora n˚agot av tre olika saker. Den kan skapa fler actors, skicka nya meddelande till andra actors eller ¨andra p˚a sitt eget tillst˚and.

Meddelandena som skickas l¨aggs i k¨o och exekveras i den ordning de togs emot. Actor- modellen till˚ater att tusentals eller till och med miljontals actors k¨ors samtidigt vilket g¨or att den l¨ampar sig mycket bra f¨or parallellisering.

2.4.2 Data race

Ett vanligt problem som uppst˚ar vid parallellprogrammering i objektorienterade och imperativa spr˚ak ¨ar data race. Ett data race ¨ar n¨ar tv˚a olika tr˚adar samtidigt modifierar samma resurs utan synkronisering, vilket resulterar i att resursen blir korrupt. Encore har l¨ost detta genom att anv¨anda actor modellen, d¨ar tr˚adar endast kommunicerar genom att skicka meddelanden fr˚an en actor till en annan. D¨armed finns inga gemensama resurser och data race kan ej ske.

(13)

2.4.3 Skalbarhet

Datorers ber¨akningsf¨orm˚aga ¨okar idag fr¨amst genom ¨okat antal k¨arnor per processor. I takt med att processorer f˚ar fler k¨arnor och dessa teknologier blir mer l¨attillg¨angliga ¨ar det viktigt att programmeringsspr˚ak kan nyttja f¨orb¨attringarna och skala bra ¨aven i fram- tiden. Encore ¨ar framtidss¨akert d˚a det st¨odjer ett stort antal actors som k¨ors samtidigt utspritt p˚a alla de processork¨arnor som finns tillg¨angliga.

2.5 Kompilatorer

En kompilator ¨ar ett program vars uppgift ¨ar att ta en k¨allkod f¨or att sedan tolka den och skapa en exekverbar kod [WG96]. Kompilatorn ¨ar en viktig del vid implementationen av spr˚akfunktioner, d˚a den genererar all information om koden som LSP-servern sedan kommer anv¨anda. En kompilator kan ofta delas upp i tv˚a distinkta delar, en f¨orsta del som utf¨or en spr˚akanalys samt en andra kodgenererande del. Spr˚akanalysen kan i sin tur delas upp i flera steg:

• Preparser, innan kompilatorn kan b¨orja tolka k¨allkoden plockas kommentarer bort och eventuella macro:n expanderas.

• Parser, best¨ammer vad som ¨ar syntaktiskt ’riktigt’ skriven kod, dvs. att koden f¨oljer programmeringsspr˚akets grammatiska regler. Samtidigt som parsern g˚ar igenom den givna koden skapar den en intern struktur oftast i form av ett ab- stract syntax tree, AST [WG96, s.123]. AST ¨ar en representation av k¨allkoden i tr¨adform, d¨ar ordning och noder ges av programmeringsspr˚akets syntax. I senare steg av kompilering kan tr¨adet uppdateras och noderna f˚a ytterligare informa- tion, kallat attribut. Om Parser:n skulle hitta ett syntaktiskt fel under tiden, t.ex.

felplacerade eller felstavade nyckelord, s˚a avbryter den och returnerar ett felmed- delande.

• Type check, till skillnad fr˚an parser:n som kollar att koden ¨ar r¨att grammatiskt, kollar Type check:ern p˚a vad koden g¨or. Type check:ern ser till att koden ¨ar konse- kvent med datatyper vid bland annat variabeldeklaration, funktionsanrop och re- turnering [WG96, s.183]. T.ex. f¨or funktionen void foo(string bar) som f¨orv¨antar sig en textstr¨ang s˚a kommer foo(4) ge ett fel, medan foo("baz")

¨ar helt korrekt.

• Avsockra, tar bort syntaktiskt socker ifr˚an koden. Syntaktiskt socker ¨ar uttryck som l¨aggs till i spr˚aket f¨or att g¨ora det l¨attare f¨or m¨anniskor att l¨asa och skri-

(14)

va [Ray96, s.432]. Ett exempel f¨or m˚anga programmeringsspr˚ak ¨ar foo+=bar som kan skrivas foo=foo+bar.

• Optimering, efter att kompilatorn skapat ett AST ¨over koden samt kollat att ko- den ¨ar korrekt b˚ade grammatiskt och i inneh˚all kan kompilatorn b¨orja optimera.

M˚anga olika s¨att finns att optimera koden, t.ex. genom att ¨andra ordning p˚a kod.

Detta steg ¨ar d¨aremot inte relevant f¨or v˚art projekt d˚a AST har redan all den in- formation som beh¨ovs.

Efter de stegen har kompilatorn en klar intern struktur ¨over hur programmet ¨ar upp- byggt. Med detta kan kompilatorn sedan ¨overs¨atta det till en exekverbar kod genom den andra delen, kodgenereraren. Den kodgenererande delen ¨ar inte viktigt f¨or detta projekt och d¨arf¨or beskrivs det mindre utstr¨ackning. Generellt utf¨or kodgenereraren tre viktiga funktioner, den avg¨or vilka resurser som beh¨ovs, best¨ammer hur och i vilken ordning AST tr¨adet ska tolkas och slutligen skapar instruktioner eller maskinkod baserat p˚a AST tr¨adet och dess noder.

3 Syfte, m ˚al och motivation

Nedan beskrivs det ¨overgripande syftet, m˚alen som ¨ar satta samt motivationen bakom projektet.

3.1 Syfte

Det ¨overgripande syftet ¨ar att g¨ora det enklare f¨or utvecklare att arbeta med programme- ringsspr˚aket Encore. Detta ˚astadkoms genom att implementera st¨od f¨or spr˚akfunktioner.

En m˚algrupp som kommer ha l˚ag prioritet ¨ar de som l¨ar sig programmera f¨or f¨orsta g˚angen. Det har visat sig att en utvecklingsmilj¨o som ¨ar bra f¨or en erfaren programme- rare kan ha negativ effekt p˚a inl¨arningsprocessen f¨or en nyb¨orjare [OA16].

Implementationen av spr˚akfunktioner ¨ar ofta m¨odosam och eftersom varje utvecklings- milj¨o i regel kr¨aver sin egen implementation blir det v¨aldigt mycket arbete att st¨odja alla popul¨ara utvecklingsmilj¨oer. L¨osningen ¨ar att anv¨anda LSP d˚a st¨odet f¨or spr˚akfunktioner bara beh¨over implementeras en g˚ang, tillsammans med en enkel klient f¨or varje utveck- lingsmilj¨o som ska st¨odjas. Eftersom st¨od f¨or att implementera LSP-klienter redan finns tillg¨angliga f¨or n¨astan alla popul¨ara utvecklingsmilj¨oer blir arbetet avsev¨art mindre.

(15)

Med en implementation av LSP f¨or Encore kommer befintliga utvecklare som anv¨ander spr˚aket kunna bedriva sin utveckling p˚a ett effektivare s¨att, dessutom kan nya anv¨andare lockas d˚a de kan utveckla f¨or Encore i sin befintliga utvecklingsmilj¨o. Det underl¨attar

¨aven f¨or utvecklarna av Encore d˚a de kan l¨agga till funktioner och direkt f˚a st¨od f¨or spr˚akfunktioner f¨or dem i alla utvecklingsmilj¨oer.

3.2 M ˚al

M˚alet med projektet ¨ar att ha en fungerande och v¨alskriven grundl¨aggande implemen- tation av LSP f¨or Encore. M˚alet ¨ar inte att implementationen ska vara komplett med alla de spr˚akfunktioner som finns tillg¨angliga utan ist¨allet att den ¨ar v¨alstrukturerad och v¨aldokumenterad. Anledningen till detta ¨ar att jobbet att implementera alla funktioner

¨ar stort och det ¨ar d¨arf¨or viktigt att det ¨ar enkelt f¨or uppdragsgivaren att kunna bygga vidare p˚a implementationen i framtiden.

3.3 Motivation

Ett vanligt problem med nya eller mindre programmeringsspr˚ak ¨ar att utvecklings- milj¨oer ofta har begr¨ansat eller inget st¨od f¨or spr˚akfunktioner. N¨ar m˚anga av de funk- tionaliteter som utvecklare f¨orv¨antar sig saknas kan det l¨att bli ett hinder. Det ¨ar d¨arf¨or intressant f¨or utvecklarna av ett programmeringsspr˚ak att tillhandah˚alla dessa, om de vill f˚a folk intresserade av just deras spr˚ak. Bra utvecklingsverktyg ¨ar ¨aven av intresse f¨or utvecklarna av Encore, d˚a det underl¨attar utveckling samt underh˚all av Encore.

I nul¨aget finns det endast grundl¨aggande funktionalitet f¨or utveckling i Encore och bara f¨or utvecklingsmilj¨on Emacs. Det finns ett flertal funktionaliteter som man kan imple- mentera f¨or att underl¨atta utveckling i spr˚aket, n˚agra av de som saknas n¨amns i 2.2.

Genom att g¨ora detta i LSP f¨orsvinner plattformsberoendet, d˚a alla utvecklingsmilj¨oer som st¨odjer LSP kan anv¨andas. Dessutom ¨ar det ett mycket enklare jobb att underh˚alla och utveckla endast en implementation.

3.4 Avgr ¨ansningar

Arbetet med att implementera spr˚akfunktioner ¨ar v¨aldigt stort. Dels f¨or att det finns v¨aldigt m˚anga spr˚akfunktioner, men ¨aven eftersom systemet ska fungera p˚a ett snabbt och effektivt s¨att. Ut¨over detta ¨ar Encore kompilatorn inte byggd f¨or att k¨oras konti- nuerligt, vilket den kommer g¨ora som LSP-server. Mycket av tiden kommer g˚a ˚at att

(16)

implementera basen f¨or LSP-servern, detta inneb¨ar att vi endast kommer implemente- ra tv˚a spr˚akfunktioner, vilka ¨ar hover och diagnostik. De resterande spr˚akfunktionerna l¨amnar vi som framtida arbete, se sektion 13.1.

Det finns fler anledningar till varf¨or valet av spr˚akfunktion att implementera blev ho- ver. Det ¨ar fr¨amst med anledning av att den implementation f¨or att visa information ligger till grund f¨or andra spr˚akfunktioner. Men ¨aven f¨or att hover tydligt demonstrerar anv¨andbarheten av implementationen, eftersom den ger tydlig visuell feedback.

Ut¨over hover valdes ¨aven diagnostik att implementera. Anledningen till detta ¨ar att di- agnostik ¨ar anv¨andbart och enkelt att implementera n¨ar st¨od f¨or hover finns. Samt att felmeddelanden genereras av kompilatorn och d¨armed redan finns tillg¨angliga.

4 Relaterat arbete

Det finns ingen befintlig implementation av LSP i Encore. D¨arf¨or best˚ar relaterade ar- beten endast av implementationer av LSP f¨or andra programmeringsspr˚ak. Eftersom att alla relaterade arbetena f¨oljer LSP standarden ¨ar strukturerna mycket lika. Skillnaden ligger fr¨amst i hur de h¨amtar information om kod. Servern ¨ar den som tillhandah˚aller information till utvecklingsmilj¨on. I vissa fall ¨ar den implementerad som en del av kom- pilatorn, i andra fall ett frist˚aende program som kommunicerar med kompilatorn.

4.1 Emacs support

Utvecklarna av Encore har tidigare anv¨ant sig av en l¨osning som de sj¨alva implementerat f¨or utvecklingsmilj¨on Emacs [GNU18]. Implementation ¨ar mycket enkel och anv¨ander sig inte av LSP eller liknande teknologier. Ist¨allet anv¨ander den sig av regulj¨ara ut- tryck f¨or att ˚astadkomma syntax highlighting. F¨or diagnostik anv¨ander den till¨agget Flycheck [Wie14] som ¨ar exklusivt f¨or Emacs. F¨or att implementera samma st¨od i and- ra utvecklingsmilj¨oer kr¨avs mer eller mindre en helt ny implementation av koden, d˚a den ¨ar mycket t¨att kopplad till Emacs. Kostnaden f¨or underh˚allet ¨okar hastigt om flera milj¨oer ska st¨odjas och begr¨ansningarna med implementationen blir tydliga.

4.2 CQuery language server

CQuery ¨ar en implementation av LSP f¨or programmeringsspr˚aken C, C++ och Objective-

(17)

all information som servern beh¨over f¨or att kunna tillgodose klienten finns tillg¨anglig.

N¨ar en f¨or¨andring sker i ett dokument, s˚a som tillagd eller borttagen text, s˚a uppdaterar indexer:n informationen i databasen. Indexer:n ¨ar ett system vars jobb ¨ar att kontinuer- ligt uppr¨atth˚alla databasen och se till att informationen alltid ¨ar den senaste. F¨or att ana- lysera koden och f˚a ut information s˚a anv¨ander den sig av kompilatorn Clang. Clang ¨ar en popul¨ar, produktionsf¨ardig kompilator f¨or programmeringsspr˚ak i C-familjen [Lt16a]

som erbjuder ett API [Lt16b] som CQuery anv¨ander sig av.

Denna implementation liknar den som anv¨ands f¨or v˚ar implementation av LSP f¨or En- core, d˚a den har ungef¨ar samma systemstruktur med en server, databas och indexer. En skillnad ¨ar att vi har m¨ojlighet att g¨ora ¨andringar direkt i kompilatorn medans CQuery ist¨allet m˚aste f¨orlita sig p˚a de funktioner som finns tillg¨angliga i Clangs API.

5 Metod

D˚a v˚ar implementation ¨ar en mindre del av ett st¨orre forskningsprojekt ¨ar det viktigt att allt v˚art arbete sker ordentligt och med god kvalitet. Spr˚akfunktionerna som ska imple- menteras m˚aste f¨olja vissa standarder f¨or att ens f˚a interageras med resten av Encore.

5.1 Language Server Protocol (LSP)

Language server protocol [Mic15] ¨ar en ¨oppen standard utvecklad av Microsoft som specificerar hur kommunikation av information f¨or spr˚akfunktioner mellan en klient och en server ska ske. Klienten ¨ar en del av en utvecklingsmilj¨o eller annat verktyg som tillhandah˚aller spr˚akfunktioner till anv¨andaren. Eftersom klienten endast f¨ormedlar informationen mellan servern och utvecklingsmilj¨on ¨ar den mycket enkel att implemen- tera. Informationen ifr˚an servern produceras i sin tur med hj¨alp av en kompilator. Kom- munikationen mellan klienten och servern sker i form av meddelanden i JSON-RPC vilket ¨ar en dialekt av JSON, d¨ar en dialekt ¨ar en version med vissa till¨agg eller mindre skillnader. I detta fall finns till¨aggen f¨or att g¨ora det m¨ojligt att f¨orvara funktionsanrop i formatet. LSP anv¨ander sig av funktionsanropen f¨or att skicka f¨orfr˚agningar mellan servern och klienten.

F¨ordelen med LSP ¨ar att specifikationen ¨ar standardiserad och d¨armed beh¨ovs det bara en implementation av servern f¨or varje programmeringsspr˚ak. Sedan kan den anv¨andas av alla typer av klienter. Tack vare detta besparas utvecklarna av servern ett enormt arbete genom att bara beh¨ova st¨odja en implementation. Den st¨orsta nackdelen ¨ar att servern och klienten inte har m¨ojlighet att kommunicera annan information ¨an den som

(18)

st¨ods av standarden, vilket medf¨or att det s¨atts en begr¨ansning p˚a de spr˚akfunktioner som kan st¨odjas.

Sedan LSP kom ut under 2015 har det dykt upp implementationer av servrar f¨or de flesta vanliga och dessutom mindre vanliga programmeringsspr˚ak [Sou17]. Det finns ett flertal av implementationer tillg¨angliga med ¨oppen k¨allkod och utg¨or d¨armed en bra grund f¨or att l¨ara sig mer om LSP.

P˚a grund av f¨ordelarna med att anv¨anda LSP har vi, tillsammans med intressenterna, valt det till v˚ar implementation. Det hade varit alltf¨or tidskr¨avande att implementera flera separata l¨osningar f¨or alla de milj¨oer som folk kan t¨ankas vilja utveckla Encore i.

5.2 Visual Studio Code

Visual Studio Code [Mic18] ¨ar en utvecklingsmilj¨o utvecklad av Microsoft som st¨odjer de tre vanligaste platformarna, Windows, MacOS och Linux. Milj¨on har st¨od f¨or van- liga verktyg som debugger och olika typer a hj¨alpmedel. Dessutom har den st¨od f¨or till¨agg vilket g¨or att vem som helst kan implementera funktionalitet som inte finns tillg¨anglig, alternativt hitta en implementation som n˚agon annan gjort. P˚a senare tiden har Visual Studio Code blivit en av de mest popul¨ara utvecklingsmilj¨oerna f¨or m˚anga anv¨andare [Sta18]

5.3 Funktionell programmering

Funktionell programmering ¨ar en vanlig programmeringsparadigm [Lip11] som objekt- orienterad eller imperativ. Grunderna i funktionell programmering ¨ar kompositionering av funktioner som bildar andra funktioner med vilka data transformeras utan sidoeffek- ter. Detta ˚astadkoms genom icke-muterbar data, dvs. data som inte kan f¨or¨andras efter att den blivit tilldelad sitt ursprungliga v¨arde. Funtkioner saknar dessutom sidoeffekter och ger alltid samma resultat f¨or samma inv¨arde, de ¨ar s˚a kallade pure.

5.4 Haskell

Haskell ¨ar ett funktionellt programmeringsspr˚ak [Lip11] som kompilatorn f¨or Encore

¨ar implementerad i. P˚a s˚a vis kan Encore-kompilatorn dra nytta av de olika f¨ordelar som funktionell programmering ger. Haskell har ¨aven en mycket kraftig typs¨akerhet som medf¨or att risken f¨or buggar minskar. Detta d˚a kompilatorn direkt uppt¨acker om

(19)

utvecklaren f¨ors¨oker anv¨anda fel typ av data i funktioner.

Med anledning av att kompilatorn f¨or Encore ¨ar skriven i Haskell anv¨ands det ¨aven f¨or implementationen av LSP-servern, s˚a den enkelt ska kunna kommunicerar med kompi- latorn. Anledningen ¨ar att endast ett program beh¨over skrivas och ingen kommunikation m˚aste ske mellan server och kompilator annat ¨an genom anrop av funktioner. Detta un- derl¨attar vid testning och implementation av nya funktioner i kompilatorn. En nackdel med att servern ¨ar implementerad i Haskell ¨ar att medlemmarna i projektet har mindre kunskap i Haskell och d¨arf¨or har varit tvungna att l¨ara sig Haskell innan arbete med implementationen kunde p˚ab¨orjas.

5.5 Git och Github

Under projektet har vi anv¨ant oss av git via tj¨ansten GitHub f¨or versionshantering. Git ger en komplett historik ¨over alla ¨andringar som har skett i projektet tillsammans med beskrivningar ¨over vad som har ¨andrats [CS18]. Detta g¨or det enkelt att h˚alla reda p˚a vad som har gjorts i projektet samt att det ¨ar enkelt att ˚angra ¨andringar som har introducerat fel i projektet.

Utvecklarna av Encore anv¨ander sig ¨aven av GitHub under utvecklingen av spr˚aket, vil- ket ¨ar anledningen till att vi ocks˚a anv¨ander det. N¨ar projektet ¨ar klart kan utvecklarna enkelt se en historik ¨over vad vi har gjort och p˚a ett enkelt s¨att integrera v˚art projekt in i deras, med en pull request. Att g¨ora en pull request p˚a GitHub inneb¨ar att man skickar en f¨orfr˚agan att l¨agga till kod i ett projekts officiella GitHub kodbas. Deras administ- rat¨orer kan se ¨andringar och antingen godk¨anna och d¨armed acceptera att ¨andringarna introduceras i huvudprojektet, eller neka. D¨arf¨or ¨ar det viktigt att g¨ora meningsfulla och v¨aldokumenterade ¨andringar.

6 Systemstruktur

Implementationen av LSP f¨or programmeringsspr˚aket Encore ¨ar uppdelad i fr¨amst tv˚a delar, som kan ses i fig 4, LSP-klienten i utvecklingsmilj¨on och Encore-delen som best˚ar av en LSP-server, en databas samt ett gr¨anssnitt mot kompilatorn. Det som ¨ar imple- menterat sedan tidigare ¨ar kompilatorn samt de utvecklingsmilj¨oer som st¨odjer LSP.

Projektet fungerar som en brygga mellan dem.

(20)

Figur 4 ¨Overgripande bild av totala systemstrukturen.

6.1 Utvecklingsmilj ¨ o och klient

Utvecklingsmilj¨oer som st¨odjer LSP, t.ex. Visual Studio Code och Emacs, kr¨aver till¨agg f¨or att aktivera LSP funktionaliteten f¨or varje spr˚ak. Dessa till¨agg kallas LSP-klienter, de ¨ar simpla och g˚ar snabbt att implementera.

Nya klienter beh¨ovs skrivas f¨or varje utvecklingsmilj¨o. Klienterna utf¨or inga spr˚akfunktioner utan specificerar endast hur kommunikationen med en servern ska ske samt f¨or vil- ka filtyper som LSP-st¨odet finns. N¨ar en fil ¨oppnas i utvecklingsmilj¨on m¨arker den av fil¨andelsen och klienten kopplar upp sig mot en LSP-server, servern tillhandah˚aller se- dan informationen som utvecklingsmilj¨on beh¨over f¨or att utf¨ora spr˚akfunktioner.

6.2 Gr ¨anssnittet

D˚a kompilatorn ¨ar fr¨amst utformad f¨or att omvandla k¨allkod till exekverbar kod, ¨ar det inte enkelt att h¨amta ut informationen som kr¨avs just f¨or LSP. Gr¨anssnittet g¨or det l¨attare att h¨amta ut relevant information ifr˚an kompilatorn f¨or LSP-servern. Gr¨anssnittet ska- pades dessutom f¨or att Encore-kompilatorn fortfarande utvecklas och kommer troligtvis

(21)

¨andras mycket under utvecklingens g˚ang. Gr¨anssnittet till˚ater ¨andringar genom att skapa en modul som st˚ar f¨or all kommunikation mellan servern och kompilatorn. Detta g¨or det

¨aven l¨att att integrera projektet med Encore d˚a n¨astan ingen befintlig kod i kompilatorn har ¨andrats.

6.3 Servern

Servern k¨ors i en separat process fr˚an utvecklingsmilj¨on, den startas antingen direkt av utvecklingsmilj¨on eller manuellt av anv¨andaren. Klienten kan sedan ansluta sig via n¨atverk eller via direktkommunikation mellan processerna d˚a LSP erbjuder b¨agge. N¨ar en f¨orbindelse har uppr¨attats kan klienten skicka information samt f¨orfr˚agningar och servern skickar svar samt notifikationer om diagnostik, mm. Servern best˚ar av en LSP- tolkare och en databas. LSP-tolkaren l¨aser, tolkar och svarar p˚a LSP-meddelanden me- dan databasen inneh˚aller relevant information f¨or koden.

Databasen sparar kontinuerligt uppdaterade textdokument med samma text som anv¨andaren ser i sin utvecklingsmilj¨o, inte det som ¨ar lokalt sparat p˚a datorn. N¨ar en f¨or¨andring sker hos anv¨andaren uppdateras ocks˚a kopian i databasen. Koden kompileras och relevant in- formation sparas. Databasen sparar ¨aven information ifr˚an tidigare kompileringar. N¨ar servern tar emot LSP-f¨orfr˚agningar anropar den databasen f¨or att h¨amta information fr˚an en tidigare kompilering. Om det beh¨ovs kan den ¨aven anropa kompilatorn via gr¨anssnittet f¨or att f˚a ny information om koden.

(22)

7 Krav och utv ¨arderingsmetoder

F¨or att projektet ska bidra positivt till Encore ¨ar kodkvaliteten n˚agot av det viktigas- te. Med det menas b˚ade att koden ska vara fels¨aker och l¨att att f¨orst˚a. Den b¨or vara v¨al och utf¨orligt kommenterad, samt f¨olja den best¨amda kodkonventionen f¨or Encore- projektet [Et18], t.ex. val av funktionsnamns och indentering. Vi har ¨aven satt som krav att implementera spr˚akfunktionerna hover och diagnostik eftersom de ¨ar enkla att testa och implementera.

Utv¨arderingen av projektets resultat och kodkvalitet kommer ske i tre steg. F¨orsta ste- get ¨ar att kontinuerligt ge presentationer p˚a hur programmet fungerar p˚a de veckoliga m¨otena med Encore gruppen s˚a att vi f˚ar feedback och kan hitta brister i ett tidigt skede.

Det andra steget, n˚agot som sker l¨opande under projektets g˚ang, ¨ar att sj¨alva g˚a igenom koden f¨or att verifiera att vi h˚aller en god kodkvalitet. Det tredje steget ¨ar att skicka en pull requestp˚a Encores GitHub sida. Om det d¨oms vara bra accepteras koden och blir en del av Encore. Finns det mindre fel kommer de pekas ut s˚a att vi kan r¨atta dem. Bed¨oms koden vara av f¨or l˚ag kvalitet kommer v˚aran pull request nekas och inte bli en del av Encore.

Ytterligare tv˚a kvantifierbara delm˚al tagits fram f¨or att testa v˚ar implementation, kra- schs¨akerhet samt responsivitet.

• LSP-servern ska ej krascha. Detta ¨ar ett uppenbart krav, men ¨and˚a viktigt p˚a grund av Encore-kompilatorns uppbyggnad. Den ¨ar utformad f¨or att avslutas efter ett fel har uppt¨ackts. LSP-servern ska, ist¨allet f¨or att avslutas, spara dessa fel och skicka dem till LSP-klienten som kan visa felet f¨or anv¨andaren.

• Att anv¨anda en spr˚akfunktion ska k¨annas responsivt. Om spr˚akfunktionerna in- te h¨anger med anv¨andarens hastighet kommer de inte anv¨andas. En handling k¨anns omedelbar om programmet har en f¨ordr¨ojning p˚a h¨ogst 0.1 sekunder. En f¨ordr¨ojning p˚a mer ¨an 0.1 sekunder men h¨ogst 1.0 sekunder m¨arker anv¨andaren, men inte tillr¨ackligt f¨or att p˚averka arbetsfl¨odet [Nie93, kapitel 5]. V˚ara funktio- ner kr¨aver inte att de ska k¨annas som omedelbara, gr¨ansen f¨or dem kommer d¨arav vara 1.0 sekunder.

F¨or att verifiera att programmet har bra responsivitet och kraschs¨akerhet kommer vi utf¨ora tv˚a typer av tester. Den f¨orsta typen ¨ar manuella tester, dvs. vi testar sj¨alva att programmet beter sig som v¨antat, vilket kontinuerligt kommer anv¨andas under utveck- lingen. Den andra typen ¨ar automatiserade tester, vilka genomf¨ors med hj¨alp av en egen- utvecklad och specialutformad klient. Den egenutvecklade klienten ska kunna skicka

(23)

8 Implementation

Implementationen best˚ar av en server, en klient och ett gr¨anssnitt. Tillsammans arbetar de med att tillhandah˚alla information fr˚an kompilatorn till utvecklingsmilj¨on.

8.1 Klient

Projektet fokuserar fr¨amst p˚a att bygga upp en grundl¨aggande implementation av LSP.

P˚a grund av detta har endast en klient implementerats f¨or att anv¨andas under testning.

Klienten ¨ar implementerad som ett till¨agg f¨or Visual Studio Code. Anledningen till valet av Visual Studio Code ¨ar att det finns bra och v¨aldokumenterat st¨od f¨or att implementera LSP-klienter. Detta i form av ett kodbibliotek [Mic18] vilket g¨or att klienten snabbt och enkelt kan implementeras precis som tanken ¨ar med LSP-klienter.

Implementationen av klienten best˚ar av en huvudfil samt n˚agra yttligare grundl¨aggande filer som kr¨avs f¨or att skapa ett till¨agg f¨or Visual Studio Code. Koden f¨or klienten ¨ar skriven i Typescript, vilket ¨ar standarden f¨or till¨agg f¨or Visual Studio Code.

Klienten startar antingen en LSP-server eller ansluter till en befintlig s˚adan beroende p˚a inst¨allningarna. Kommunikationen med servern sker sedan ¨over n¨atverk eller genom direktkommunikation mellan processer. Den funktionalitet som klienten kan erbjuda anv¨andaren avg¨ors under uppstart d˚a servern rapporterar den funktionalitet som st¨odjs.

Efter uppstarten skickar klienten f¨orfr˚agningar till servern n¨ar anv¨andaren anv¨ander n˚agon av de funktioner som st¨ods, sedan svarar servern med relevant information. Att skicka sj¨alva f¨orfr˚agningarna ¨ar en uppgift som ligger p˚a utvecklingsmilj¨on och ¨ar inte n˚agot som klienten tar hand om. Detta inneb¨ar att klienten fr¨amst vidarebefordrar infor- mationen mellan utvecklingsmilj¨on och servern, detta leder till att LSP-klienter ¨ar enkla att implementera.

8.2 Server

Servern ¨ar implementerad som en del av Encore-kompilatorn. Gr¨anssnittet f¨or kommu- nikation mellan server och kompilator beskrivs mer ing˚aende i sektion 8.3.

Servern best˚ar av tv˚a st¨orre delsystem. Det f¨orsta delsystemet hanterar kommunikatio- nen med klienten. Detta sker sedan ¨over n¨atverket eller genom direktkommunikation mellan processer. St¨od f¨or alla dessa finns som en del av Haskells standardbibliotek och beh¨over d¨arf¨or inte implementeras. N¨ar ett meddelande n˚ar servern fr˚an klienten han- teras detta med hj¨alp av en dedikerad meddelandehanterare f¨or just det meddelandet.

(24)

Alternativt skickas ett felmeddelande tillbaka om servern inte kan hantera meddelandet.

Meddelandehanteraren avg¨or sedan vad som ska ske och vid behov anv¨ander den sig av funktionerna fr˚an det andra delsystemet p˚a servern.

Det andra stora delsystemet best˚ar av en databas som inneh˚aller alla koddokument som en klient arbetar med. Databasen ¨ar ingen extern databas utan ist¨allet en enkel data- struktur. Servern ¨ar implementerad s˚a att den inte ska beh¨ova k¨oras p˚a samma maskin som klienten. Det ¨ar d¨arf¨or viktigt att servern inte tolkar namnen p˚a dokumenten som deras s¨okv¨agar i filsystemet d˚a dessa ¨ar relativa s¨okv¨agar hos klienten och kanske inte motsvarar samma plats i filsystemet p˚a servern. Detta medf¨or att servern m˚aste ha egna kopior av alla dokument, d˚a kompilatorn m˚aste ha alla dokument f¨or att kunna kompi- lera. N¨ar ett dokument f¨or¨andras hos klienten p˚a grund av att anv¨andaren lagt till eller tagit bort kod skickas ett meddelande till servern om f¨or¨andringen. Servern uppdaterar d˚a dokumentet i databasen f¨or att reflektera ¨andringen.

Tillsammans med dokumenten i databasen f¨orvaras ¨aven information om det kompile- rade programmet. N¨ar en f¨or¨andring sker i ett dokument kompileras ¨aven koden i de dokument som ber¨ors av f¨or¨andringen. N¨ar koden i ett dokument har kompilerats upp- dateras databasen med den senaste informationen. Om ett fel sker under kompilering beh˚alls den befintliga informationen om programmet och databasen uppdateras ist¨allet med information om felet.

N¨ar servern tar emot en f¨orfr˚agan fr˚an klienten anv¨ands informationen fr˚an databasen f¨or att generera svaret. F¨or att finna den korrekta information fr˚an det kompilerade pro- grammet i databasen anv¨ands gr¨anssnittet mellan servern och kompilatorn. Dessa funk- tioner underl¨attar jobbet med att finna information i databasen, vilket ¨ar n¨odv¨andigt d˚a databasen kan inneh˚alla stora m¨angder information. Funktionerna ¨ar implementerade s˚a att de har m¨ojlighet att hitta information djupt inuti rekursiva datastrukturer. Den utvunna informationen formateras slutligen och skickas sedan tillbaka till klienten.

8.3 Gr ¨anssnitt

Mellan servern och kompilatorn finns det ett gr¨anssnitt. Gr¨anssnittet har implementerats som en rad funktioner som servern kan anv¨anda f¨or att h¨amta information fr˚an kompi- latorn.

(25)

Figur 5 Hello world program i Encore.

8.3.1 Hover

N¨ar servern f˚ar en hover-f¨orfr˚agan anv¨ands funktioner fr˚an gr¨anssnittet f¨or att h¨amta informationen. Funktionen utg˚ar fr˚an representationen av det kompilerade programmet och positionen som skickas med i f¨orfr˚agan. Programmet s¨oks igenom tills den del av programmet som motsvarar positionen har hittats. Informationen utvinns sedan fr˚an platsen och skickas tillbaka till servern.

Att h¨amta information baserat p˚a position ¨ar mer komplext ¨an det verkar p˚a grund av hur positioner fungerar, se exempelkoden i figur 5. Om vi vill h¨amta information om funktionen println p˚a rad 3 kan vi inte bara fr˚aga efter noden som inneh˚aller den raden och den kolumnen, eftersom b˚ade metoden main samt klassen Main ocks˚a inneh˚aller den positionen. Ist¨allet m˚aste vi fr˚aga efter den noden som inneh˚aller positionen samt har den kortaste l¨angden.

8.3.2 Diagnostik

N¨ar ett koddokument ¨oppnas eller ¨andras skickar klienten en uppdatering till servern.

Servern anv¨ander d˚a gr¨anssnittet f¨or att initiera en kompilering. Om ett fel uppt¨acks un- der kompilationen vidarebefordrar gr¨anssnittet felet till servern som slutar i att anv¨andaren f˚ar se det.

9 Utv ¨arderingsresultat

Utv¨arderingen av de krav och m˚al som beskrivs i sektion 7 presenteras f¨oljande. Det ¨ar fr¨amst p˚a tre omr˚aden som vi har utv¨arderat. Dessa ¨ar kodkvaliteten, kraschhantering samt responsivitet.

(26)

9.1 Kodkvalitet

Efter kontinerligt kontrollerat koden anser vi att vi har en bra kodkvalitet. D˚a detta i n˚agon m˚an ¨ar subjektivt har vi skickat en pull request till Encore projektets Github sida, s˚a att de f˚ar avg¨ora. Eventuella anm¨arkningar kommer vi i s˚a fall ˚atg¨arda.

9.2 Kraschhantering

Eftersom Haskells typsystem garanterar att inga kraschar kan ske utanf¨or kod med sido- effekter kan man vara s¨aker p˚a att det inte kan ske p.g.a. felformaterade meddelanden.

Om ett felformaterat meddelande mottags skickas ist¨allet ett felmeddelande tillbaka till klienten, men endast om felet beror p˚a felaktig JSON-RPC. Ifall felet beror p˚a n˚agot annat g˚ar det inte att forts¨atta kommunikationen p.g.a. LSP-protokollets utformning, d˚a st¨anger servern ist¨allet anslutningen och v¨antar p˚a att klienten ˚ateransluter. Eftersom kompilatorn anv¨ander sig av sidoeffekter kan den orsaka riktiga krascher, d¨arf¨or ¨ar alla anrop till kompilatorn skyddade med felhantering som meddelar klienten om fel in- tr¨affar.

9.3 Responsivitet

Under v˚ara manuella tester med kortare kodstycken visas felmeddelanden fr˚an dia- gnostikfunktionen p˚a s˚a kort tid att f¨ordr¨ojningar inte ¨ar m¨arkbara, de ¨ar troligtvis under 0,2s. ¨Aven resultat fr˚an hover-funktionen visas mycket snabbt, dock lite l˚angsammare med ungef¨ar 0,5s f¨ordr¨ojning.

Vi har ¨aven implementerat en egen LSP-klient som skickar f¨orfr˚agningar och m¨ater hur l¨ange det tar f¨or servern att svara. Denna klient ¨ar implementerad i TypeScript eftersom det finns m˚anga f¨ardiga funktioner tillg¨angliga som har gjort implementationen enklare.

Klienten anv¨andes f¨or att skicka olika meddelanden, till exempel kod inneh˚allande olika fel f¨or att m¨ata tiden f¨or diagnostik. Samt korrekt kod f¨or att m¨ata tiden f¨or hoverfunk- tionerna. Alla tester utf¨ordes p˚a en laptop med specifikationerna som finns i appendix A.

F¨or alla tester skickades flera stycken av autogenererad kod som varierar mellan 8 och 2000 rader. Koden best˚ar endast av en klass inneh˚allande ett varierande antal funktio- ner som alla har en parameter och som alla inneh˚aller ett anrop till println. Klassen inneh˚aller ¨aven en main-funktion som anropar alla andra funktioner i klassen.

(27)

Figur 6 Svarstid f¨or diagnostik vid syntax-fel

• N¨ar koden ¨andras f¨or att inneh˚alla ett syntax-fel i form av en avsaknad slut- parentes mottas diagnostiken av klienten tillbaka p˚a under 0,2s, detta kan ses i figur 6.

• N¨ar koden ¨andras f¨or att inneh˚alla ett typfel i form av ett flyttal d¨ar ett heltal f¨orv¨antas mottas diagnostiken av klienten p˚a under 0,5s, detta kan ses i figur 7.

• N¨ar korrekt kod har skickats och hover-funktionen anv¨ands mottas resultatet alltid mellan 41-43ms, eftersom det ¨ar mycket enkelt f¨or servern att s¨oka igenom AST- tr¨adet n¨ar det v¨al ¨ar genererat.

Alla resultat m¨oter kravet p˚a svar under 1s med god marginal. F¨or filer med avsev¨art mycket mer ¨an 2000 rader kod eller om servern k¨ors p˚a en dator med s¨amre prestanda

¨ar det m¨ojligt att kravet inte skulle m¨otas. Eftersom det m¨ots f¨or dessa typexempel anser vi att kravet f¨or projektet som helhet har uppfyllts.

10 Resultat

Resultatet av projektet kan ses som tre avgr¨ansade delar. F¨orsta delen ¨ar LSP-klienten som ¨ar ett till¨agg till utvecklingsmilj¨on Visual Studio Code. Andra delen ¨ar servern som tar emot och svarar p˚a f¨orfr˚agningar fr˚an klienten. Tredje delen ¨ar ett gr¨anssnitt mot kompilatorn som anv¨ands f¨or att utvinna information ur kod. Nedan presenteras resultatet f¨or dessa tre delar.

(28)

Figur 7 Svarstid f¨or diagnostik vid typ-fel

10.1 Klient

Klienten ¨ar en v¨al fungerande del av projektet. Detta resultat ¨ar v¨antat eftersom imple- mentationen skiljer sig mycket lite fr˚an referensimplementationen av en LSP-klient f¨or Visual Studio Code.

10.2 Server

Servern ¨ar i ett stadie d¨ar det planerade st¨odet f¨or hover och diagnostik finns implemen- terat. St¨odet f¨or hover ¨ar inte komplett i den mening att den inte kan hantera information f¨or alla delar av ett program, utan ett urval av dessa. I diskussionen i sektion 11 tas dessa begr¨ansningar upp.

10.3 Gr ¨anssnitt

Gr¨anssnittet inneh˚aller funktioner f¨or bland annat hantering av felmeddelanden och positioner samt st¨od f¨or att kompilera Encore-program utan att kompilering avbryts.

Gr¨anssnittet skulle potentiellt kunna utg¨ora grunden f¨or ett framtida kompilator API, vilket beskrivs mer ing˚aende i sektion 13.4.

(29)

11 Diskussion

Klienten best˚ar av mycket lite kod, endast ett par tiotal rader, vilket g¨or att den gick v¨aldigt fort att implementera. Detta ¨ar grundid´en med LSP d˚a det ska vara enkelt att skapa klienter. Andra utvecklingsmilj¨oer med liknande kodbibliotek som Visual Studio Code [Mic15] kommer med stor sannolikhet vara lika enkla att l¨agga till st¨od f¨or. Pre- standa och tillg¨anglighet f¨or spr˚akfunktioner ¨ar helt beroende av servern eftersom det ¨ar servern som tillhandah˚aller all information.

Ett problem som uppkom n¨ar vi implementerade servern var att kompilatorn inte utfor- mades f¨or att st¨odja denna typ verktyg. D¨arf¨or har det under utvecklingen av servern va- rit n¨odv¨andigt att l¨agga till de funktioner i kompilatorn som vanligtvis g¨ors tillg¨angliga genom ett API, som t.ex. CQuery vilket beskrivs i sektion 4.2. Det blev en utmaning eftersom vi var tvungna att s¨atta oss in i kompilatorns interna struktur.

Ett annat problem som uppstod var vid implementationen av hover. Det visade sig att kompilatorn var inkonsekvent i hur den hanterar positioner, dvs. den motsvarande posi- tionen i kodtexten, under kompilationen. Som exempel p˚a en inkonsekvens s˚a omfattar positionen f¨or ett funktionsanrop alla delar av anropet, ¨aven parametrarna. F¨or operato- rer ¨ar positionen d¨aremot endast given f¨or operatorn och inte operanderna. Detta ledde till att det kr¨avdes mycket specifik kod f¨or att hantera positionerna f¨or olika uttryck ist¨allet f¨or en generaliserad kod. Problemet med att skriva specifik kod ¨ar att det ¨ar tidskr¨avande och att det uppkommer repetition vilket ¨okar risken f¨or buggar. D¨arav ¨ar endast n˚agra varianter implementerade, t.ex. funktionsanrop.

D˚a det tidigare endast fanns enklare st¨od f¨or spr˚akfunktioner i Encore f¨or Emacs s˚a ¨ar resultatet en klar f¨orb¨attring. Utvecklarna har nu m¨ojlighet att anv¨anda andra milj¨oer

¨an Emacs under utveckling och det ¨ar enkelt f¨or en utvecklare att l¨agga till st¨od f¨or ytterligare utvecklingsmilj¨oer. Servern ¨ar dock inte f¨ardigutvecklad och kan d¨arf¨or inte j¨amf¨oras mot f¨ardiga implementationer f¨or andra programmeringsspr˚ak. Anledningen

¨ar att de ofta har utvecklats under en l¨angre tid och har b¨attre st¨od fr˚an den kompilator som anv¨ands. I vissa fall ¨ar det ¨aven s˚a att kompilatorn skrivits med en baktanke att verktyg s˚a som LSP ska vara l¨att att implementera.

(30)

12 Slutsatser

V˚art projekt resulterade i b¨orjan p˚a en LSP-implementation f¨or Encore. Den uppfyllde de krav och avgr¨ansningar som angavs i b¨orjan, dvs. en solid och v¨al utformad grund att bygga vidare p˚a med enklare funktioner f¨or att demonstrera grundl¨aggande funktio- nalitet. De spr˚akfunktioner som implementerades var hover samt diagnostik.

13 Framtida arbete

P˚a grund av storleken p˚a detta projektet kommer det kr¨avas en del framtida arbete f¨or att slutf¨oras. LSP st¨odjer mycket funktionalitet och detta arbete implementerar endast n˚agra av dem.

13.1 Fullst ¨andig implementation av LSP

Det finns 21st spr˚akfunktioner definierade i LSP-specifikationen [Mic15], vi har f¨or n¨arvarande bara implementerat tv˚a av dessa. Ett bra framtida arbete skulle vara att im- plementera funktionaliteterna som saknas. N˚agra av dessa som har ¨onskats av intressen- terna att implementera ¨ar.

• Go to definition, visar var en given symbols definition ¨ar i nuvarande eller annat textdokument.

• Rename, byter namn p˚a alla f¨orekomster av en symbol som anv¨ands i hela pro- jektet.

• Kodkomplettering, ger f¨orslag p˚a forts¨attningar av koden f¨or en given textposi- tion. En illustration kan ses i fig 1.

13.2 LSP-Klienter

F¨or att kunna anv¨anda implementationen av LSP kr¨avs ett till¨agg till varje utvecklings- milj¨o, dessa kallas klienter. ¨An s˚a l¨ange har endast en klient skrivits, den ¨ar utvecklad f¨or Visual Studio Code. Att implementera en LSP-klient ¨ar trivialt [Mic15] s˚a l¨ange det finns st¨od f¨or LSP i utvecklingsmilj¨on, vilket g˚ar att se h¨ar [Sou17]. Saknas st¨od f¨or LSP

(31)

i utvecklingsmilj¨on beh¨ovs det f¨orst implementeras innan man kan skapa en LSP-klient, men detta ligger p˚a utvecklarna av utvecklingsmilj¨on.

13.3 Effektivitet

Effektivitet ¨ar en viktig f¨orb¨attring f¨or projektet. Ett program som ¨ar effektivare kan snabbare svara p˚a f¨orfr˚agningar och anv¨ander mindre energi, vilket ¨ar viktigt f¨or laptops vid batteridrift.

Den enklaste implementationen av LSP-servern l˚ater kompilatorn kompilera om hela programmet vid varje knapptryckning fr˚an anv¨andaren, n˚agot den nuvarande imple- mentationen g¨or. Problemet som uppst˚ar d˚a ¨ar att mycket arbete m˚aste genomf¨oras hela tiden. En effektivare implementation skulle vara att endast kompilera om de delar som

¨ar nya. Ett framtida arbete skulle vara att implementera st¨od f¨or partiell kompilation, en- dast kompilera en liten kodsnutt. F¨or att den funktionaliteten ska vara anv¨andbar kr¨avs

¨aven att LSP-servern kan sammanfoga det gamla kompileringsresultatet med den nya partiella kompileringen.

13.4 Separation av server fr ˚an kompilator

Nuvarande implementation av server och kompilator ¨ar t¨att kopplade och ¨ar implemen- terade som ett program. Allt utbyte av information sker med ett hj¨alp av ett gr¨anssnitt.

F¨ordelen med detta ¨ar att det blir l¨att att distribuera LSP-servern. Nackdelen ¨ar att LSP- servern alltid f¨oljer med kompilatorn, ¨aven f¨or de som inte vill anv¨anda den.

En f¨orb¨attring hade varit att dela upp implementation av servern och kompilatorn i tv˚a tydligt separerade program. Samtidigt hade det nuvarande gr¨anssnittet mot kompilatorn utgjort en stabil grund att implementera ett API f¨or kompilatorn p˚a. Detta API som d˚a hade varit en del av kompilatorn hade ist¨allet anv¨ants av servern f¨or att implementera den funktionalitet som den i nul¨aget anv¨ander gr¨anssnittet f¨or. Denna implementation hade varit mer lik hur andra programmeringsspr˚ak hanterar utvinnandet av information fr˚an kompilatorn. Ett exempel ¨ar Clang som har ett liknande API tillg¨angligt [Lt16b]. En f¨ordel med ett s˚adant API ¨ar att det blir l¨attare att utveckla andra verktyg, som utnyttjar information som kompilatorn kan generera.

(32)

Referenser

[CS18] S. Chacon and B. Straub, Pro Git, 2nd ed., 2018.

[Duf16] J. Dufault. (2016) cquery. [Online]. Available: https://github.com/cquery- project/cquery

[Et17] Encore-team. (2017) The encore programming language. [Online]. Available:

https://stw.gitbooks.io/the-encore-programming-language/

[Et18] ——. (2018) Encore coding conventions. [Online]. Available: https://github.

com/parapluu/encore/blob/development/CONTRIBUTING.md

[GNU18] GNU. (2018) Emacs. [Online]. Available: https://www.gnu.org/software/

emacs/

[Hew77] C. Hewitt, “Viewing control structures as patterns of passing messages,” Arti- ficial Intelligence, vol. 8, no. 3, pp. 323–364, 1977.

[Lip11] M. Lipovaca, Learn You a Haskell for Great Good! No Starch Press, 2011.

[Lt16a] LLVM-team. (2016) clang: a c language family frontend for llvm. [Online].

Available: https://clang.llvm.org/

[Lt16b] ——. (2016) clang tooling api. [Online]. Available: http://clang.llvm.org/docs/

LibTooling.html

[Mic15] Microsoft. (2015) Language server protocol. [Online]. Available: https:

//microsoft.github.io/language-server-protocol/specification

[Mic18] ——. (2018) Visual studio code. [Online]. Available: https://code.visualstudio.

com/docs/extensions/overview

[Nie93] J. Nielsen, Usability Engineering, new edition ed. Boston, Ma, USA: AP Professional, 1993.

[OA16] A. T. Owoseni and S. A. Akanji, “Survey on adverse effect of sophisticated in- tegrated development environments on beginning programmers’ skillfulness,”

International Journal of Modern Education and Computer Science(IJMECS), vol. 8, no. 9, pp. 28–34, 2016.

[Ray96] E. S. Raymond, The New Hacker’s Dictionary, 3rd ed. Cambride, Ma, USA:

The MIT Press, 1996.

(33)

[Sou17] Sourcegraph. (2017) Language server implementations. [Online]. Available:

https://langserver.org/

[Sta18] Stack Exchange Inc. (2018) Developer survey results 2018. [Online].

Available: https://insights.stackoverflow.com/survey/2018

[UpS17] UpScale. (2017) Upscale. [Online]. Available: https://upscale.project.cwi.nl/

[WG96] W. M. Waite and G. Goos, Compiler Construction. Berlin, De: Springer- Verlag, 1996. [Online]. Available: https://www.cs.cmu.edu/aplatzer/course/

Compilers/waitegoos.pdf

[Wie14] S. Wiesner. (2014) Flycheck. [Online]. Available: http://www.flycheck.org/

en/latest/index.html

(34)

A Specifikationer

Haskell GHC version 7.10.3

CPU Intel Core i5-4200H 2.80GHz

RAM Samsung DDR3L-1600 SODIMM 8GB CL11 OS Fedora 27 (Linux 4.15.10-300.fc27.x86 64)

References

Related documents

Element¨ ar gruppteori, hemuppgifter till torsdag vecka 401. Vilka element kan v¨aljas som generator f¨ or

L¨ angden (mm) av bultarna varierar p˚ a grund av ett slumpm¨ assigt fel som antas vara normalf¨ ordelat kring 0 med standardavvikelsen σ = 0.5 vilket motsvarar precisionen f¨

F¨or att f¨orvissa oss om att s˚ a ¨ar fallet g¨or vi oss en bild av situationen

I en produktionsprocess blir enheterna, oberoende av varandra, felak- tiga med sannolikhet 0.01 och 300 enheter tillverkas. I en urna finns vita och

Man kan faktiskt g¨ora ett konfidensintervall f¨or medianen med konfidensgrad minst lika med 1 − α helt utan n˚ agra som helst antaganden om den bakom- liggande f¨ordelningen

L¨ osningen till uppgift 2(b)(ii) fr˚ an provduggan Vi m˚ aste visa tv˚ a

Po¨ angen p˚ a godk¨ anda duggor summeras och avg¨ or slutbetyget.. L¨ osningarna skall vara v¨ almotiverade och

[Tips: Faktorisera polyno-