Even Wiik Thomassen committed 4e24866

Fix some captions.

Comments (0)

Files changed (4)

-    \lstinputlisting[style=hcr,gobble=0,numbers=left,basicstyle=\tiny]{./code/lambda.hcr}
+    \lstinputlisting[style=hcr,gobble=0,numbers=left,nolol,basicstyle=\tiny]{./code/lambda.hcr}
+    \vspace{-10pt}
     \mycpt{Double lambda example: external Core output}{(Z-decoded)}{lst:lambda-core}
-    \lstinputlisting[style=hcj,gobble=0]{./code/lambda.hcj}
+    \lstinputlisting[style=hcj,gobble=0,nolol]{./code/lambda.hcj}
+    \vspace{-10pt}
     \caption{Double lambda example: \corejs{}'s JSCore output\label{lst:lambda-jscore}}
 	note = "[Online; accessed 07-12-2012]"
-% extcore2? howpublished = "\url{}",
 	author = {Peyton Jones, Simon and Fischer, James},
 	title = {{Haskell Bug Tracker: Ticket 5844 - Panic on generating Core code}},
     address = {Trondheim, Norway},
+    author = {Peyton Jones, Simon and Marlow, Simon and others},
+	title = {{GHC} source code, git repository},
+	howpublished = "\url{}",
+	year = {2012},
+	note = "[Online; accessed 29-12-2012]"
 External Core representation of a Haskell source file is produced by giving
 \gls{ghc} the flag \mycode{-fext-core}, and the \extcore\footnote{%
-External Core parser package \extcore on HackageDB:
+External Core parser package, \extcore, on HackageDB:\\
 \url{}} package support parsing and
 working with external Core in Haskell.
 It is not only external Core that causes problems for PyHaskell. The
 \extcore package has been abandoned, and was last updated over a year
-ago. According to Haskell's online package library,
-HackageDB\footnotemark[\value{footnote}], \extcore support \gls{ghc} version
-7.0. A few of the things external Core support is not supported by \extcore,
-for example \todo{TODO}.
+ago. According to HackageDB\footnotemark[\value{footnote}], Haskell's online
+package library, \extcore support \gls{ghc} version 7.0 or older. Therefor
+there are some things external Core support, that is not supported by \extcore.
+\todo{TODO: For example}
 The \extcore package also has some unwanted behavior. For example, it convert
 lambda-statements that have more than one variable into several
-lambda-statements with one variable each. The \corejs{}-program in
-\citet{skrede}'s pipeline has some more issues, such as the \gls{json}-encoding
-of external Core is verbose. It is more verbose than what is required to encode
-it as \gls{json}.
+lambda-statements with one variable each.
+The \corejs{}-program in \citet{skrede}'s pipeline has some more issues, such
+as the \gls{json}-encoding of external Core is too verbose. It is more verbose
+than what is required to encode it as \gls{json}.
 In \autoref{app:extcore} we list an example where \extcore split a lambda into
 two lambdas. Line six and seven of \mylst{lambda-core} is a two-variable
 size. These examples also show how a simple function is represented in external
 Core as one lambda with two case-expressions.
-Improvements to \corejs would not be beneficial until the problems
-further up the pipeline are solved. A better approach at such a stage might be
-to completely scrap \corejs, and parse external Core directly.
+Improvements to \corejs would not be very beneficial until the problems
+further up the pipeline are solved. When other, larger issues are removed, it
+might be better to completely scrap \corejs, and write a new parser that can
+parse external Core directly.
 the Haskell Prelude, these language extensions are used in great number. For
 TODO: give example, list some of the extensions, give footnote about
 TODO: External Core does not support these language extensions??
-	\mycpt{Haskell-Python pipeline by}{\citet{skrede}}{fig:pipeline}
+	\mycpt{Haskell-Python's pipeline}{by \citet{skrede}}{fig:pipeline}
 The \gls{ghc} frontend handle parsing and type-checking of Haskell source
 code before it desugar Haskell into the Core intermediate representation.