1. Even Wiik Thomassen
  2. thesis

Commits

Even Wiik Thomassen  committed 62bbabb

More extcore

  • Participants
  • Parent commits 09fb67c
  • Branches default

Comments (0)

Files changed (1)

File extcore.tex

View file
 %--------------------
 \label{sec:limitations}
 In addition to the issues mentioned, the external Core approach has several
-limitations that must be also be solved before PyHaskell can support the full
+limitations that must be also be solved before PyHaskell can fully support the
 Haskell language, Prelude, and test suite.
 
+\citet{hudak} note that Haskell has gained ``dozens of language extensions
+(notably in the type system)''~\cite[p.~29]{hudak}. In the newer versions of
+the Haskell Prelude, these language extensions are used in great number. For
+example,
+TODO: give example, list some of the extensions, give footnote about
+extensions.
 
-\mytodo{use this paragraph somewhere in here}
-``Over the fifteen years of its life so far, GHC has grown a huge num-
-ber of features. It supports dozens of language extensions (notably
-in the type system), an interactive read/eval/print interface (GHCi),
-concurrency (Peyton Jones et al., 1996; Marlow et al., 2004), trans-
-actional memory (Harris et al., 2005), Template Haskell (Sheard
-and Peyton Jones, 2002), support for packages, and much more be-
-sides. This makes GHC a dauntingly complex beast to understand
-and modify and, mainly for that reason, development of the core
-GHC functionality remains with Peyton Jones and Simon Marlow,
-who both moved to Microsoft Research in 1997.''~\cite[p.~29]{hudak}
+TODO: External Core does not support these language extensions??
+
+TODO: C stuff.
 
 
 \section{Improvements}
 could be based on an already existing Iface Core printer, BinIface, that
 support serialization and deserialization of Iface Core.
 
+Mention that external Core has almost no tests, and a first step of rewriting
+must be to create tests to ensure the rewrite generates the same grammar as
+the current implementation.
+
 \subsection{GHC API}
 \label{sec:ghc-api}
 External Core is not the only way to use \gls{ghc} as a frontend. As described
 
 \section{Discussion}
 %-------------------
+``Over the fifteen years of its life so far, \gls{ghc} has grown a huge number
+of features (\ldots) This makes \gls{ghc} a dauntingly complex beast to
+understand and modify and, mainly for that reason, development of the core
+\gls{ghc} functionality remains with Peyton Jones and Simon
+Marlow.''~\cite[p.~29]{hudak}
+
+In my attempts at improving \gls{ghc}'s external Core, I must agree that 
+understanding and modifying \gls{ghc} is a huge undertaking, which is futher
+\ldots by the complexity of the Haskell language itself.
+
+TODO: something about I have spendt lot of time to understand the issues and
+limitations, more more more, but been unable to solve them.
+Estimate that both solutions are probably one to two months of work for an
+experienced Haskell programmer, which I am not.
+
+It is my opinion that:
 %TODO: Suggest GHC external Core is rewritten, extcore package updated, 
 %core2js and jscparser replaced with a new parser that accepts external
 %Core files directly. JSON is just to verbose and unnecessary.