Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

stavfel

  • Loading branch information...
commit 76204c7a118303b2bfc9108c4ce88c5999058755 1 parent 9e57339
Adam Bengtsson authored
View
3  rapport/MasterThesis.tex
@@ -244,6 +244,7 @@
\bibliography{kallor}
% Appendices
-
+\appendix
+\input{kapitel/appendix.tex}\FloatBarrier
\end{document}
View
BIN  rapport/hiji_screen3.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
3  rapport/kapitel/appendix.tex
@@ -0,0 +1,3 @@
+\appendix
+\section{Bidragsrapport}
+Alla gruppmedlemmar var delaktiga i likvärdig utsträckning under planeringsfasen. Större delen av projektet har genomdrivits gemensamt men varje person har haft en inriktning enligt projektets olika delar. Johan Gustafsson har haft ansvar över parsern, Mikael Bung har ansvarat för interpretatorn och det abstrakta syntaxträdet, Mattis Jeppsson för typcheckaren och Adam Bengtsson för HIJi. Rapporten har skrivits enligt samma uppdelning men med ett övergripande ansvar av Adam Bengtsson. Arbetet har i så stor utsträckning som möjligt skett gemensamt och vi har därför både bidragit till och tagit del av varandras respektive ansvarsområde.
View
14 rapport/kapitel/diskussion.tex
@@ -2,7 +2,7 @@ \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 interpertatorn parallelt och bestämma individuellt vad som skulle implementeras och i
+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.
@@ -22,7 +22,7 @@ \subsection{Val av språk för implementering}
optimeringar i kompilatorn skulle en målrepresentation nödvändigtvis innehålla
strukturer liknande dem man finner 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 innbyggda.
+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.
@@ -37,18 +37,18 @@ \subsection{Val av språk för implementering}
\subsection{Framtida förbättringar}
-Syftet med projektet, att skapa en fungerande Haskelltolk i javascript, har vi lyckats implementera om man tar hänsyn till de avgränsningar som är uppsatta. Dock om man ser 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.
+Syftet med projektet, att skapa en fungerande Haskelltolk i Javascript, har vi lyckats implementera om man tar hänsyn till de avgränsningar som är uppsatta. Dock om man ser 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 exempelivs 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 implentera detta behöver man 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.
+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 man 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, paranteser,
-komman och hakparanteser efter \emph{let} och avgöra när det är korrekt att sätta in avslutande måsvingar.
+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å.
View
4 rapport/kapitel/inledning.tex
@@ -1,7 +1,7 @@
\section{Inledning}
På vissa av Chalmers och Göteborgs Universitets datorvetenskapliga program är den första programmeringskursen i Haskell \citep{haskell98} och för en del av de nya eleverna är inlärningströskeln hög. De studenter som börjar på de datavetenskapliga programmen på Chalmers och Göteborgs Universitet är allt från nybörjare till mycket kompetenta inom programmering. De flesta saknar dock kunskaper kring funktionell programmering. Skillnaden mellan ett funktionellt och ett objektorienterat programmeringsspråk är stora och omställningen hur programmeringsrelaterade problem behöver angripas är inte enkelt för de flesta nybörjare. Vi tror att ett interaktivt webbverktyg skulle kunna sänka tröskeln och underlätta undervisningen. Ett webbverktyg medför även att en kompilator som \emph{Glasgow Haskell Compiler} (GHC) \citep{ghc} ej behöver installeras. Webbens stöd för interaktivitet gör det möjligt att snabbt visa funktionsdeklarationerna för de inbyggda funktionerna och att enkelt evaluera funktionerna och testa sig fram till olika resultat.
-Många programmerare kommer inte i kontakt med funktionell programmering och med hjälp av ett interaktivt webbbverktyg som är enkelt för användaren att använda är vår förhoppning att fler programmerare och studenter ska komma i kontakt med funktionell programmering, och i synnerhet Haskell. Då flera moderna objektorienterade programmeringsspråk börjar ta funktionalitet och begrepp från funktionella programmeringsspråk så är det extra viktigt att programmerare kommer i kontakt med funktionell programmering. Ett exempel på detta är \emph{C\#} som i senare versioner har fått stöd för bland annat lambda-funktioner (anonyma funktioner) \citep{csharp}.
+Många programmerare kommer inte i kontakt med funktionell programmering och med hjälp av ett interaktivt webbverktyg som är enkelt för användaren att använda är vår förhoppning att fler programmerare och studenter ska komma i kontakt med funktionell programmering, och i synnerhet Haskell. Då flera moderna objektorienterade programmeringsspråk börjar ta funktionalitet och begrepp från funktionella programmeringsspråk så är det extra viktigt att programmerare kommer i kontakt med funktionell programmering. Ett exempel på detta är \emph{C\#} som i senare versioner har fått stöd för bland annat lambda-funktioner (anonyma funktioner) \citep{csharp}.
En fördel med att ha tolken på webben är att det enda som behövs för att använda den är en javascriptkompatibel webbläsare, något som följer med i alla moderna operativsystem. Detta betyder att de användare som befinner sig inom vår målgrupp redan har den programvaran som behövs på sina hemdatorer för att använda sig av vårt program.
@@ -27,7 +27,7 @@ \subsection{Syfte}
Meningen är att dessa ska kunna köras i en vanlig webbläsare utan att ladda ner en haskellkompilator, till exempel GHC, eller behöva lära sig svårbegripliga kommandon.
\subsection{Metod}
-Projektet bestod av att planera, designa och implementera haskelltolken. Vi arbetade efter en iterativ modell där nya funktioner lades till undan för undan. Detta fungerade bra eftersom vi tidigt fick en fungerande prototyp att utgå från. Arbetet delades upp i separata moduler som utvecklades relativt frånskillt från varandra för att undan för undan fasas ihop till det slutgiltliga resultatet.
+Projektet bestod av att planera, designa och implementera haskelltolken. Vi arbetade efter en iterativ modell där nya funktioner lades till undan för undan. Detta fungerade bra eftersom vi tidigt fick en fungerande prototyp att utgå från. Arbetet delades upp i separata moduler som utvecklades relativt frånskilt från varandra för att undan för undan fasas ihop till det slutgiltiga resultatet.
%I vårt arbete har vi implementerat parser, typcheckare och interpretator parallellt med varandra och utökar de olika modulernas funktionalitet iterativt.
%Vi hade tänkt följa den här planen genom varje milstolpe genom att utöka parsern, typcheckaren och interpretatorn med ny funktionalitet.
View
10 rapport/kapitel/metod.tex
@@ -5,8 +5,8 @@ \section{Metod}
\subsection{Genomförande}
% modulbaserat arbete..
-För att implementera en tolk för Haskell behövs en parser för den aktuella syntaxen, en typcheckare för språkets definerade typregler och tillsist en interpretator som tolkar språket efter dess specifikation.
-Det upptäcktes tidigt att de tre modulerna, parser, interpretator och typcheckare inte behövde utvecklas sekvensiellt. De tre modulerna intergrerar enbart med varandra genom det abstrakta syntaxträdet, vår interna representation av Haskell, vilket medför att det är lätt att utveckla de olika modulerna helt frånskilt från varandra. Figur \ref{fig:tolkens_struktur} visar hur denna interaktion mellan de olika modulerna är tänkt att gå till. Figuren visar även hur webbläsaren kommunicerar genom ett Javascript API och det abstrakta syntaxträdet och inte direkt med de olika komponenterna.
+För att implementera en tolk för Haskell behövs en parser för den aktuella syntaxen, en typcheckare för språkets definierade typregler och tillsist en interpretator som tolkar språket efter dess specifikation.
+Det upptäcktes tidigt att de tre modulerna, parser, interpretator och typcheckare inte behövde utvecklas sekvensiellt. De tre modulerna integrerar enbart med varandra genom det abstrakta syntaxträdet, vår interna representation av Haskell, vilket medför att det är lätt att utveckla de olika modulerna helt frånskilt från varandra. Figur \ref{fig:tolkens_struktur} visar hur denna interaktion mellan de olika modulerna är tänkt att gå till. Figuren visar även hur webbläsaren kommunicerar genom ett Javascript API och det abstrakta syntaxträdet och inte direkt med de olika komponenterna.
\begin{figure}[h]
\begin{center}
@@ -22,8 +22,8 @@ \subsection{Genomförande}
En interaktiv kommandotolk som kan köras i en webbläsare utvecklades. Den gav användaren möjlighet att skriva haskellfunktioner och exekvera dem på ett liknande sätt som i GHCi.
Vi integrerade jQuery \citep{jquery} för att få ett unisont stöd för samtliga webbläsare. jQuery underlättade även arbetet med att skapa ett enkelt och stilrent interaktivt gränssnitt.
-Arbetssättet präglades av en iterativ utvecklingsmetodik med korta utvecklingscyklar. Arbetet delades upp med huvudansvarstagande över var sin modul och utfördes parallellt med varandra. Arbetet skedde dock framförallt i samlad grupp på grund av att det var många designrelaterade problem vi var tvugna att ta ställning till under projektet, till exempel hur vårat abstrakta syntaxträd skulle se ut, och för att det skulle bli enklare när vi skulle börja sammanfoga våra olika moduler med varandra.
-Det var också ett bra sätt att snabbt få hjälp av varandra eftersom vi ej visste exakt hur modulerna skulle se ut när vi påbörjade arbetet. Vi fann det därför praktiskt att använde en iterativ modell för att bit för bit utvigda våra moduler. Dock valde vi att implementera typcheckaren i ett steg då vi ansåg att det skulle vara enklare. Detta främst för att vi trodde typklasser var så centralt i typcheckaren att det skulle vara svårt att lägga till det i en andra iteration.
+Arbetssättet präglades av en iterativ utvecklingsmetodik med korta utvecklingscyklar. Arbetet delades upp med huvudansvarstagande över var sin modul och utfördes parallellt med varandra. Arbetet skedde dock framförallt i samlad grupp på grund av att det var många designrelaterade problem vi var tvungna att ta ställning till under projektet, till exempel hur vårt abstrakta syntaxträd skulle se ut, och för att det skulle bli enklare när vi skulle börja sammanfoga de olika modulerna med varandra.
+Det var också ett bra sätt att snabbt få hjälp av varandra eftersom vi ej visste exakt hur modulerna skulle se ut när vi påbörjade arbetet. Vi fann det därför praktiskt att använde en iterativ modell för att bit för bit utvidga våra moduler. Dock valde vi att implementera typcheckaren i ett steg då vi ansåg att det skulle vara enklare. Detta främst för att vi trodde typklasser var så centralt i typcheckaren att det skulle vara svårt att lägga till det i en andra iteration.
Eftersom vi arbetade parallellt med olika moduler var vi beroende av ett bra versionshanteringssystem. Bra i vårt fall innebar att det skulle vara enkelt att arbeta i olika grenar, en gren för varje modul, och att det skulle gå snabbt och enkelt att slå ihop dessa förgreningar när vi behövde länka samman två utvecklares arbeten. I början av projektet använda vi oss av Subversion (SVN). Detta berodde framförallt på att det var det versionshanteringssystem som alla i gruppen hade erfarenhet från tidigare. Dock insåg vi att SVN inte var praktiskt att använda när man arbetar i flera olika grenar i projektet samtidigt. Därför gick valet till att använda Git som är designat från grunden för att på ett enkelt sätt skapa nya och slå samman förgreningar under utvecklingens gång. Vi kunde därmed skapa en förgrening för varje modul och under arbetets gång sammanlänka allas arbeten på ett effektivt sätt.
@@ -44,7 +44,7 @@ \subsubsection{JSParse}
\subsubsection{jQuery}
%jQuery är ett öppet kodbibliotek till Javascript som är dubeellicenserat under MIT License och GPL version 2.
-jQuery är designat för att underlätta för utvecklare att modifiera DOM-träd och göra asynkrona javascript-anrop. jQuery användes i projektet för att få likartat stöd i samtliga webbläsare i kommandotolken som utvecklades.
+jQuery är designat för att underlätta för utvecklare att modifiera DOM-träd och göra asynkrona javascriptanrop jQuery användes i projektet för att få likartat stöd i samtliga webbläsare i kommandotolken som utvecklades.
jQuery gav oss även möjlighet att skapa ett enkelt och stilrent interaktivt gränssnitt utan att behöva göra allt från grunden.
jQuery.Cookie, ett tillägg till jQuery, används för att förenkla användandet av kakor.
View
50 rapport/kapitel/resultat.tex
@@ -1,13 +1,13 @@
\section{Resultat}
% TODO
-Projektets resultat är ett kodbibliotek för en haskelltolk. Den nuvarande statusen av projektet är att parser och interpretator är fullt integrerade med varandra. Typcheckaren är inte integrerad, dock är den färdigutvecklad. För att integrera typcheckaren måste det abstrakta syntaxträdet utvigdas för att ta hänsyn till typinformation.
+Projektets resultat är ett kodbibliotek för en haskelltolk. Den nuvarande statusen av projektet är att parser och interpretator är fullt integrerade med varandra. Typcheckaren är inte integrerad, dock är den färdigutvecklad. För att integrera typcheckaren måste det abstrakta syntaxträdet utvidgas för att ta hänsyn till typinformation.
Koden finns att tillgå på GitHub: \url{http://github.com/johang88/haskellinjavascript}. Nedan följer en mer noggrann genomgång av projektets olika delar.
\subsection{Parser}
Parserns uppgift är att ta användarens indata och konvertera den till en datastruktur
som är lättare att hantera internt. Denna datastruktur kallas \emph{Abstract Syntax Tree} (AST).
-Haskellstandarden har definerat upp en grammatik, ett antal regler, som definerar hur korrekt haskellkod ser ut och hur den ska tolkas.
+Haskellstandarden har definierat upp en grammatik, ett antal regler, som definierar hur korrekt haskellkod ser ut och hur den ska tolkas.
Haskell är ett svårt språk att parsa då det inte är kontextfritt på grund av att kodens mening beror på blanksteg,
Haskell tillåter även användardefinierade operatorer vilket också kan påverka kodens mening.
@@ -66,11 +66,11 @@ \subsubsection{Steg 1 - Ta bort kommentarer}
nästlade som kan gå över flera rader börjar med \emph{\{-} och slutar med \emph{-\}}.
\subsubsection{Steg 2 - Applicera layoutregler}
-Det andra steget applicerar Haskells layoutregler enligt två algoritmer som är definerade i haskellstandarden \citep{haskell98chap9}. Den första delar upp koden i dess ord och symboler samtidigt som den dekoreras med indenteringsnivåer.
-Därefter användads den andra för att sätta in måsvingar och semikolon på rätt platser.
+Det andra steget applicerar Haskells layoutregler enligt två algoritmer som är definierade i haskellstandarden \citep{haskell98chap9}. Den första delar upp koden i dess ord och symboler samtidigt som den dekoreras med indenteringsnivåer.
+Därefter användas den andra för att sätta in måsvingar och semikolon på rätt platser.
När de två algoritmerna är klara sätts koden ihop igen och skickas vidare till nästa steg.
-Ett exempel på en layoutregel är att ett inre block inte får vara mer indenderat än ett omslutande block.
+Ett exempel på en layoutregel är att ett inre block inte får vara mer indenterat än ett omslutande block.
\begin{lstlisting}
case x of
True -> ...
@@ -87,7 +87,7 @@ \subsubsection{Steg 2 - Applicera layoutregler}
\begin{lstlisting}
let { x = 5; y = 4 } in x + y
\end{lstlisting}
-För att översätta detta korrekt kommer parsern ihåg den aktuella nästlingsnivån av \emph{let}-uttryck och var deras repsektive \emph{in}-uttryck befinner sig.
+För att översätta detta korrekt kommer parsern ihåg den aktuella nästlingsnivån av \emph{let}-uttryck och var deras respektive \emph{in}-uttryck befinner sig.
Den avslutande måsvingen sätts in där ett matchande \emph{in}-uttryck påträffas.
Det finns även uttryck som inte översätts korrekt, exempelvis:
@@ -103,13 +103,13 @@ \subsubsection{Steg 2 - Applicera layoutregler}
[ x | let { x = 2 ] }
\end{lstlisting}
Anledningen är att endast nästlingen av \emph{let} och \emph{in} sparas, men här finns inget \emph{in}.
-För att lösa felet måste parsern hålla reda på antalet paranteser, måsvingar, hakparanteser och komman efter ett \emph{let}-uttryck och när en symbol som gör det ogiltligt
+För att lösa felet måste parsern hålla reda på antalet parenteser, måsvingar, hakparenteser och komman efter ett \emph{let}-uttryck och när en symbol som gör det ogiltigt
med en avslutande måsvinge påträffas sätts måsvingen in precis innan symbolen.
\subsubsection{Steg 3 - Skapa AST}
-Det tredje steget är en parser för den kontextfria varianten av Haskell som den är definerad i standarden.
-Samtidigt som koden tolkas byggs en AST upp. Parsern består av en liten parser för varje grammatisk regel som är definerad i haskellstandarden.
-Dessa parsers kombineras ihop för att bilda den slutgiltliga parsern. Det resulterar i ett träd av parsers, en parser för hela programmet som har flera mindre parsers under sig.
+Det tredje steget är en parser för den kontextfria varianten av Haskell som den är definierad i standarden.
+Samtidigt som koden tolkas byggs en AST upp. Parsern består av en liten parser för varje grammatisk regel som är definierad i haskellstandarden.
+Dessa parsers kombineras ihop för att bilda den slutgiltiga parsern. Det resulterar i ett träd av parsers, en parser för hela programmet som har flera mindre parsers under sig.
Exempel på grammatik definierad i Haskellstandarden:
\begin{lstlisting}
@@ -125,8 +125,8 @@ \subsubsection{Steg 3 - Skapa AST}
Tittar vi närmare på \emph{gdrhs} ser vi att det är en rekursiv deklaration. Vilket vi implementerar med \emph{repeat1} för att få en lista med minst en upprepning.
\emph{gdrhs\_action} och \emph{gdrhs\_fix\_list\_action} används för att generera det abstrakta syntaxträdet.
-Parsern använder den metod som är specifierad i Haskell 2010 \citep{haskell2010} för att lösa företrädesreglerna (precedence levels) för operatorer då den här metoden är enklare än den som är definerad i Haskell 98.
-Anledningen till att företrädesreglerna inte kan defineras direkt i parsern är att Haskell använder sig av användardefinerade företrädesregler.
+Parsern använder den metod som är specificerad i Haskell 2010 \citep{haskell2010} för att lösa företrädesreglerna (precedence levels) för operatorer då den här metoden är enklare än den som är definierad i Haskell 98.
+Anledningen till att företrädesreglerna inte kan definieras direkt i parsern är att Haskell använder sig av användardefinierade företrädesregler.
Metoden fungerar så att den löser företrädesreglerna först efter ett uttryck har parsats till en lista med operatorer
och uttryck, när en operator påträffas i listan slås dess företrädesnivå upp i en tabell och ett träd med
operatorer och uttryck skapas. Till sist används trädet för att generera en AST för uttrycken.
@@ -140,7 +140,7 @@ \subsubsection{JSParse}
Parsers som vi har lagt till:
\begin{enumerate}
\item{\emph{repeatn}: en parser som upprepar en parser minst \emph{n} antal gånger}
- \item{\emph{expectws}: en parser som tillåter blanksteg och inte returnerar någon ast, är en kombination av JSParse inbyggda parsers \emph{expect} och \emph{whitespace}}
+ \item{\emph{expectws}: en parser som tillåter blanksteg och inte returnerar någon AST, är en kombination av JSParse inbyggda parsers \emph{expect} och \emph{whitespace}}
\end{enumerate}
\subsection{Typcheckare}
@@ -286,7 +286,7 @@ \subsubsection{Defaulting}
Ofta förekommer situationer där tvetydigheter gör att typcheckaren inte kan bestämma en typ. För att förenkla för programmeraren finns därför förbestämda standardtyper att använda i dessa situationer för en del inbyggda typer. Detta användande av förbestämda standartyper kallas för defaulting.
\subsubsection{Typcheckarens nuvarande status}
-I sitt nuvarande tillstånd saknar typcheckaren delar av den funktionalitet som ingick i projektets mål. Detta handlar om integration med interpretatorn och förmågan att ladda rätt instans av typklassser vid applicering av överlagrade funktioner.
+I sitt nuvarande tillstånd saknar typcheckaren delar av den funktionalitet som ingick i projektets mål. Detta handlar om integration med interpretatorn och förmågan att ladda rätt instans av typklasser vid applicering av överlagrade funktioner.
\subsection{Interpretatorns struktur}
Interpretatorns uppgift är att tolka det abstrakta syntaxträdet. Under interpreteringen används flera datastrukturer vars uppgift och struktur anges här.
@@ -301,7 +301,7 @@ \subsubsection{Thunk}
Haskell måste använda sig av \emph{non-strict evaluation}, vilket innebär att en uträkning inte får köras ifall den inte behövs. När en uträkning körs så innebär det att den resulterar i flertalet \emph{Thunks} för de delar av beräkningen som ännu inte behövs. När värdet av en \emph{Thunk} behövs kommer den att tvingas till en \emph{Weak Head Normal Form} (WHNF) eller en ny \emph{Thunk}. Anledningen till detta är att vi på så sätt minskar användandet av rekursion vilket minskar risken att vi får ett runtime error.
\subsubsection{Weak Head Normal Form}
-En WHNF är ett partiellt evaluerat uttryck. Uttrycket har blivit evaluerat så långt att vi är säkra på att det retunerar något typ av värde, alltså något som inte är \emph{undefined}. Ofta innehåller en WHNF referenser till ännu icke evaluerade uttryck, om de inte gör det sägs uttrycket vara i \emph{Normal Form}.
+En WHNF är ett partiellt evaluerat uttryck. Uttrycket har blivit evaluerat så långt att vi är säkra på att det returnerar något typ av värde, alltså något som inte är \emph{undefined}. Ofta innehåller en WHNF referenser till ännu icke evaluerade uttryck, om de inte gör det sägs uttrycket vara i \emph{Normal Form}.
\begin{lstlisting}
data WeakHead
@@ -311,7 +311,7 @@ \subsubsection{Weak Head Normal Form}
| Primitive
\end{lstlisting}
-En \emph{Data} är resultatet av att applicera en algebraisk datakonstruktor på dess argument. Argumenten ges som en lista av \emph{HeapPtr}, det vill säga en lista av evaluerade eller icke evaluerade uttryck. Exemplevis resulterar \emph{Just 1} i en \emph{Data} med Identifiern \emph{Just} och en \emph{HeapPtr} till det icke evaluerade uttrycket 1.
+En \emph{Data} är resultatet av att applicera en algebraisk datakonstruktor på dess argument. Argumenten ges som en lista av \emph{HeapPtr}, det vill säga en lista av evaluerade eller icke evaluerade uttryck. Exempelvis resulterar \emph{Just 1} i en \emph{Data} med Identifiern \emph{Just} och en \emph{HeapPtr} till det icke evaluerade uttrycket 1.
En \emph{LambdaAbstraction} är körningsrepresentationen av en lambda-funktion, en \emph{Env} är bunden till lambda-funktionen.
@@ -320,7 +320,7 @@ \subsubsection{Weak Head Normal Form}
En \emph{Primitive} är ett Javascript-värde, till exempel en \emph{integer} eller en \emph{double}.
\subsubsection{HeapPtr}
-De flesta implementationer av Haskell använder sig av lat evaluering, vilket innebär att en \emph{Thunk}, ett uttryck, kommer att tvingas maximalt en gång. I vår implementation används \emph{HeapPtr} som en wrapper runt en \emph{Thunk}, när en \emph{HeapPtr} dereferenceras kommer \emph{Thunk} att tvingas till en WHNF och \emph{HeapPtr} uppdateras att peka till denna. Eftersom att tvingandet av en \emph{Thunk} kan resultera i en ny \emph{Thunk} så tvingas thunken i en loop till dess att resultatet är en WHNF.
+De flesta implementationer av Haskell använder sig av lat evaluering, vilket innebär att en \emph{Thunk}, ett uttryck, kommer att tvingas maximalt en gång. I vår implementation används \emph{HeapPtr} som en wrapper runt en \emph{Thunk}, när en \emph{HeapPtr} dereferensera kommer \emph{Thunk} att tvingas till en WHNF och \emph{HeapPtr} uppdateras att peka till denna. Eftersom att tvingandet av en \emph{Thunk} kan resultera i en ny \emph{Thunk} så tvingas thunken i en loop till dess att resultatet är en WHNF.
\begin{lstlisting}
this.dereference = function() {
@@ -340,7 +340,7 @@ \subsubsection{HeapPtr}
En \emph{HeapPtr} är ett vanligt Javascript-objekt som innehåller funktionen \emph{dereference}. \emph{Dereference} körs när anroparen vill använda den WHNF som \emph{HeapPtr} pekar mot. Om \emph{HeapPtr} inte har blivit dereferenserad innan så kommer dess \emph{Thunk} att tvingas tills det att resultatet är en WHNF och \emph{HeapPtr}-objektet uppdateras till att peka mot denna.
\subsubsection{Env}
-Env är en stack av \emph{Javascript hashes}. Hasharna består av en bindning mellan en \emph{Identifier} och antingen en \emph{HeapPtr} eller ett (\emph{Pattern}, \emph{HeapPtr}) par. Den andra bindingstypen är resultatet av en \emph{VariableDeclaration} där man måste utföra en \emph{pattern match} för att avgöra vilken \emph{HeapPtr} som hör till vilken \emph{Identifier}. När man läser ut en \emph{Identifier} som är bunden enligt den andra typen av binding, kommer en \emph{pattern match} att utföras och alla \emph{identifiers} i det \emph{pattern} som matchas kommer att bindas om som den första typen alternativt en \emph{pattern match fail} inträffar och ett \emph{exception} genereras.
+Env är en stack av \emph{Javascript hashes}. Hasharna består av en bindning mellan en \emph{Identifier} och antingen en \emph{HeapPtr} eller ett (\emph{Pattern}, \emph{HeapPtr}) par. Den andra bindningstypen är resultatet av en \emph{VariableDeclaration} där man måste utföra en \emph{pattern match} för att avgöra vilken \emph{HeapPtr} som hör till vilken \emph{Identifier}. När man läser ut en \emph{Identifier} som är bunden enligt den andra typen av bindning, kommer en \emph{pattern match} att utföras och alla \emph{identifiers} i det \emph{pattern} som matchas kommer att bindas om som den första typen alternativt en \emph{pattern match fail} inträffar och ett \emph{exception} genereras.
\begin{lstlisting}
Env {
@@ -355,7 +355,7 @@ \subsubsection{Env}
\end{lstlisting}
\subsection{Abstrakt syntaxträd och evaluering}
-Vår AST representeras av javascript-objekt men dess strukturella uppbyggnad ges här av Haskells datadefinitioner.
+Vår AST representeras av javascriptobjekt men dess strukturella uppbyggnad ges här av Haskells datadefinitioner.
\subsubsection{Declaration}
Den första datatypen av intresse är \emph{Declaration}. En \emph{Declaration} representerar en namnbindning antigen i en moduls globala definitionsområde eller i en \emph{let}- eller \emph{where}-bindning.
@@ -378,7 +378,7 @@ \subsubsection{Declaration}
\end{lstlisting}
Värt att notera här är avsaknaden av typvariabler och typargument, detta kommer att åtgärdas när typcheckaren är integrerad.
-Under interpreteringen av en \emph{Declaration} binds de namn (Identifiers) som definieras av \emph{Declaration} till \emph{Env}-objektet. Vilken typ av binding som används beror på typen av \emph{Declaration}. En \emph{Variable} ger en \emph{Identifier => (Pattern, Expression)}-bindning medan en \emph{Function} eller \emph{Data} ger en \emph{Identifier => Expression}-bindning.
+Under interpreteringen av en \emph{Declaration} binds de namn (Identifiers) som definieras av \emph{Declaration} till \emph{Env}-objektet. Vilken typ av bindning som används beror på typen av \emph{Declaration}. En \emph{Variable} ger en \emph{Identifier => (Pattern, Expression)}-bindning medan en \emph{Function} eller \emph{Data} ger en \emph{Identifier => Expression}-bindning.
\subsubsection{Expression}
En \emph{Expression} är representationen av ett haskelluttryck.
@@ -435,8 +435,8 @@ \subsubsection{Pattern}
\subsection{HIJi}
-HIJi är ett program som ger användaren ett GHCi-liknande användargränssnitt till haskelltolken i en webläsare.
-HIJi tar indata genom att funktioner skrivs in i HIJi som sedan tolkas av parsern och i sin tur bygger upp det abstrakta syntaxträdet. Därefter evalueras uttrycket av interpretern och resultatet blir synligt i HIJi.
+HIJi är ett program som ger användaren ett GHCi-liknande användargränssnitt till haskelltolken i en webbläsare.
+HIJi tar indata genom att funktioner skrivs in i HIJi som sedan tolkas av parsern och i sin tur bygger upp det abstrakta syntaxträdet. Därefter evalueras uttrycket av interpretatorn och resultatet blir synligt i HIJi.
HIJi har stöd för att ladda externa moduler. Det görs genom att skriva :l \emph{namn-på-modul}. Användaren får då tillgång till alla de funktioner som är skrivna i den modulen. Modulerna måste vara placerade på servern som HIJi laddades ifrån. Modulerna kan ej laddas direkt från användarens hårddisk på grund av att Javascript av säkerhetsskäl ej har läs- och skrivrättigheter av användarens filsystem. HIJi har även en förladdad modul, Prelude, som innehåller en delmängd av de funktioner som GHCi har i sin motsvarighet.
@@ -451,16 +451,16 @@ \subsection{HIJi}
\end{center}
\end{figure}
-Figur \ref{fig:hiji} visar hur HIJi ser ut. De första raderna visar, precis som i GHCi, vilka moduler som för närvarande är laddade. I det här exemplet är den förladdade modulen Prelude laddad. Därefter följer en kommandotolk där användaren fritt kan skriva in egna funktioner. I figuren är en lambda-funktion inskriven.
+Figur \ref{fig:hiji} visar hur HIJi ser ut. De första raderna visar, precis som i GHCi, vilka moduler som för närvarande är laddade. I det här exemplet är den förladdade modulen Prelude laddad. Därefter följer en kommandotolk där användaren fritt kan skriva in egna funktioner. Figuren visar ett antal olika exempel på hur HIJi kan användas.
HIJi är skapat för att likna GHCi i så stor utsträckning som möjligt.
Genom att efterlikna GHCi kommer användare känna igen sig när de tar steget från HIJi till GHCi. Det blir för dem ett naturligt steg och kortar inlärningströskeln. Även för haskellprogrammerare som är vana användare av GHCi blir det lättare att använda sig av HIJi, de behöver inte fundera hur verktyget ska användas.
\subsection{Prelude}
I våra avgränsningar angav vi vilka delar av haskellspecifikationen vi skulle fokusera på. De delar som vi har fullt stöd för är lambda-funktioner, namngivna funktioner, algebraiska datatyper, pattern matching och guards.
-I HIJis förladdade modul, Prelude, har vi definerat upp ett antal funktioner som visar på att vi har implementerat dessa egenskaper från specifikationen.
+I HIJis förladdade modul, Prelude, har vi definierad upp ett antal funktioner som visar på att vi har implementerat dessa egenskaper från specifikationen.
Alla funktioner som är definierade i Prelude är namngivna funktioner. Ett exempel på en namngiven funktion är \emph{id}.
-Algebraiska datatyper stöds och i Prelude har vi definerat upp datatypen Bool och ett par funktioner, däribland (||), som använder sig utav den här datatypen. Funktionen (||) använder sig av pattern matching. Resultatet av \emph{case x of} kommer matcha antingen mot \emph{True} eller \emph{False}.
+Algebraiska datatyper stöds och i Prelude har vi definierat upp datatypen Bool och ett par funktioner, däribland (||), som använder sig utav den här datatypen. Funktionen (||) använder sig av pattern matching. Resultatet av \emph{case x of} kommer matcha antingen mot \emph{True} eller \emph{False}.
Funktionen \emph{filter} från Prelude är ett exempel på att guards fungerar. Filter är också ett exempel på att pattern matching och rekursiva funktioner är implementerade.
\begin{lstlisting}
View
2  rapport/kapitel/sammanfattning.tex
@@ -7,7 +7,7 @@
\\
\\
Resultatet består av en parser, typcheckare, interpretator och ett användargränssnitt liknande GHCi.
- Parsern tar användaren indata och konverterar den till en intärn datastruktur, kallat abstrakt syntaxträd. Typcheckaren analyserar sedan det abstrakta syntaxträdet för att kontrollera att det ej förekommer några typfel. Om inga fel har påträffats så skickas trädet vidare till interpretatorn som tolkar trädet på ett väldefinerat vis.
+ Parsern tar användaren indata och konverterar den till en intern datastruktur, kallat abstrakt syntaxträd. Typcheckaren analyserar sedan det abstrakta syntaxträdet för att kontrollera att det ej förekommer några typfel. Om inga fel har påträffats så skickas trädet vidare till interpretatorn som tolkar trädet på ett väldefinierat vis.
\\
\\
Resultatet visar att det är möjligt att implementera Haskell i Javascript, men det behövs mycket mer arbete för att skapa en nybörjarvänlig miljö att lära sig Haskell i.
View
2  rapport/kapitel/slutsatser.tex
@@ -5,5 +5,5 @@ \section{Slutsatser}
Vi har beskrivit hur vi med parser combinators har implementerat Haskells layoutregler och grammatik, en typcheckare som kan typchecka Haskell enligt de regler som haskellstandarden föreskriver samt en interpretator som tolkar Haskell med lat evaluering. Slutligen beskriver vi HIJi, ett enkelt användargränssnitt till haskelltolken.
-En rad förbättrningsåtgärder har identifierats för att göra tolken mer användbar för nybörjare. Främst handlar det om att göra ett snyggt interaktivt användargränssnitt till HIJi, men även att generera bättre felmeddelanden i parsern.
+En rad förbättringsåtgärder har identifierats för att göra tolken mer användbar för nybörjare. Främst handlar det om att göra ett snyggt interaktivt användargränssnitt till HIJi, men även att generera bättre felmeddelanden i parsern.
Totalt sett har projektet visat sig vara lyckat, även om vi är medvetna om att mycket finns kvar att förbättra.
Please sign in to comment.
Something went wrong with that request. Please try again.