Commits

Even Wiik Thomassen committed 6a0fe91

More changes to extcore.

  • Participants
  • Parent commits 59f2202

Comments (0)

Files changed (2)

 # Remove all generated files
 clean:
 	@echo "Removing LaTeX build files"
-	@rm -f code/*.hcj code/*.hcr code/*.hi code/*.o
+	@rm -f code/*.hi code/*.o
 	@rm -f *.aux *.toc *.log *.lof *.bbl *.blg *.acn *.out *.lot
 	@rm -f *.pyg *.glo *.ist *.tdo *.bak *.acr *.alg *.glg *.gls *.lol
 \label{cha:extcore}
 This chapter describes \gls{ghc}'s external Core current implementation and
 functionality (\autoref{sec:extcore}); issues and limitations hindering
-PyHaskell's support of the Haskell language (\autoref{sec:issues} and 
-\autoref{sec:limitations}); and solutions to these issues
-\autoref{sec:solutions};
+PyHaskell's support of the Haskell language (\autoref{sec:issues}; and
+solutions to these issues \autoref{sec:solutions}.
 
 PyHaskell use \gls{ghc} to type-check and desugar Haskell source code into
 Core, and create an external representation of Core. PyHaskell then convert
 working with external Core in Haskell.
 
 
-\section{Issues}
-%---------------
+\section{Issues and limitations}
+%-------------------------------
 \label{sec:issues}
 While Core has been improved and upgraded to different iterations based of
 \sysf (currently \sysfp), external Core has been neglected and drifted out of
 might be better to completely scrap \corejs, and write a new parser that can
 parse external Core directly.
 
-
-\section{Limitations}
-%--------------------
-\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 fully support the
-Haskell language, Prelude, and \gls{ghc}'s test suite.
+TODO: C stuff.
 
 \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.~\cite{ghcrepo}.
-
-TODO: External Core does not support these language extensions??
-
-TODO: C stuff.
+example, the \mycode{GHC.Base}-module that is imported by almost all modules
+the Prelude use the following extensions: NoImplicitPrelude, BangPatterns,
+ExplicitForAll, MagicHash, UnboxedTuples, ExistentialQuantification, and
+RankNTypes. While most of these are removed by \gls{ghc} before Core, some
+leave their marks in the code produced by external Core~\cite{ghcrepo}.
 
 
 \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.
+As \gls{ghc}'s external Core support has almost no tests, a first step of
+rewriting it must be to create tests, to ensure the rewrite generates the same
+grammar as the current implementation.
 
 \subsection{GHC API}
 \label{sec:ghc-api}
 For PyHaskell to use \gls{ghc} \gls{api} instead of external Core, it would
 need to create a Haskell program that interface with Core and serialize it
 to an external representation. Just from said description, it is obvious that
-this is the main goal of \gls{ghc}'s external Core support. While re-creating
-external Core with \gls{ghc} \gls{api} could be beneficial, it would still
-suffer from many of the limitations mentioned in \autoref{sec:limitations}.
-And creating a new syntax that is easy to serialize and parse for Core
-could be a time-consuming job in itself.
+this is the main goal of \gls{ghc}'s external Core support.
 
 The main benefit from this approach would be that we could use Core after the
 CorePrep transformation pass, which have more invariants than external Core,