\section{Diskussion}
Vi har skapat en javascriptapplikation som kan parsa, typchecka och interpretera stora delar av Haskell 98. Det som saknas är fullständigt stöd för typklasser där stödet endast finns i typcheckaren och parsern men fortfarande behöver implementeras i interpretatorn. Detta handlar främst om förmågan att välja rätt instanser av typklasser vid applicering av överlagrade funktioner.

Sett till planeringen har vi lyckats uppfylla alla milstolpar utom typklasser, dock inte enligt den ordning och tidsplan som ursprungligen planerades. 
Vi insåg att det var enklast att utveckla parsern, typcheckaren och interpretatorn parallellt och bestämma individuellt vad som skulle implementeras och i 
vilken ordning för att senare, oftast en gång i veckan, samordna och implementera det som behövdes i flera delar.

Vi har inte implementerat NPlusK-pattern i parsern och då de är borttagna i Haskell 2010 \citep{haskell2010} känner vi att det inte behövs.

\subsection{Val av språk för implementering}
Tidigt i planeringen tvingades vi välja vilket språk vår implementation skulle
bestå av. Det första alternativet var att först skriva en kompilator för att
kompilera Haskell till Javascript. Därefter skulle så kallad boot-strapping
tillämpas där kompilatorn används för att kompilera sig själv till
Javascript. Eftersom det redan finns parsers och typcheckare för Haskell
skrivna i Haskell skulle projektet mestadels handla om att finna en lämplig
målrepresentation för Haskell i javascriptkod och sedan implementering av en
kodgenerator för denna. Haskells statiska typcheckning och referentiella
transparens skulle också förenkla verifiering av projektets komponenter.

Dock finns även en del nackdelar med en sådan implementation. Utan särskilda
optimeringar i kompilatorn skulle en målrepresentation nödvändigtvis innehålla
strukturer liknande dem som kan finnas i en interpretator för ett lat evaluerat
språk. Det är ett rimligt antagande att sådana optimeringar på grund av sin komplexitet vore alltför stora för att genomföra i den aktuella tidsramen. Därför anser vi att denna typ av implementation lämpar sig bäst inom
ramarna för ett existerande kompilatorprojekt såsom GHC där nödvändiga optimeringar redan finns inbyggda.

Det andra alternativet var att skriva allt i Javascript och detta är den
implementationsstrategi som vi till slut bestämde oss för.
En fördel med en sådan implementation är att integrering med annan
javascriptkod blir enkel.
Det har också fördelen att i en interpretator bevaras kodstrukturen och en framtida interaktiv läromiljö får tillgång till mellanliggande körningsdata.
Det första alternativet skulle däremot kräva ett
särskilt integrationslager för att få samma möjligheter.


%stor del av vår projekts potentiella användare redan har viss erfarenhet av Javascript och liknande språk och att användande av vårt bibliotek därför blir enklare för dessa än vad motsvarande haskellimplementation skulle bli. Eftersom detta alternativ krävde att vi själva implementerar parser, typcheckare och interpreterare ansåg vi också att det gav oss större möjligheter till lärande. 

\subsection{Framtida förbättringar}

Syftet med projektet, att skapa en fungerande Haskelltolk i Javascript, har vi lyckats implementera om hänsyn tas till de avgränsningar som är uppsatta. Dock sett till motivationen bakom projektet, att vår Haskelltolk ska kunna användas som grund för att skapa en webbaserad interaktiv läroplattform, så finns det fortfarande mycket kvar att utveckla. Framförallt handlar det om att göra Haskelltolken och HIJi mer lättanvänd för nybörjare inom funktionell programmering.

I parsern har vi identifierat två förbättringsmöjligheter. För det första, hjälpsamma och förklarande felmeddelanden är en viktigt del av ett utvecklingsverktyg och det generars för tillfället inte av parsern. 
Om parsern stöter på ett fel rapporterar den endast att ett fel har inträffat och avslutar parsningsprocessen. 
Att förbättra dessa felmeddelanden med exempelvis rad- och kolumnnummer och specifik information om vad för fel som har inträffat skulle göra parsern mer användbar.
För att implementera detta behöver parsern kombinera steg 1 och 2 i parsningen för att rad- och kolumn-nummer ska bevaras korrekt då borttagning av nästlade kommentarer kan påverka dessa.
JSParse behöver modifieras så att det rapporterar var ett fel uppstod och i vilken parser.

För det andra, konverteringen av icke kontextfri Haskellkod till kontextfri kan förbättras 
för att klara av att expandera måsvingar i \emph{[x | let x = 5]}. 
För att klara av detta behövs en parser som räknar antal måsvingar, parenteser, 
komman och hakparenteser efter \emph{let} och avgöra när det är korrekt att sätta in avslutande måsvingar.

Även i HIJi finns det förbättringar att göra.
Det som framförallt behöver utvecklas är, för det första, erbjuda en interaktiv tutorial där användaren får instruktioner vad som ska skrivas in i HIJi. Om användaren skriver in rätt uttryck fortsätter tutorialen till nästa nivå.
För det andra, visa typinformation från funktioner genom att hålla musen över funktionsnamnet.
Och tillsist, kunna stega igenom ett program eller funktion för att kunna se vad som händer i varje evalutionssteg. 
