Tinkering with paper

Papers/Epic/conclusions.tex

@@ -1,5 +1,16 @@
 \section{Related Work}
 
+Should mention Agda and Idris~\cite{scrap-engine} and the development
+version of Epigram~\cite{levitation} as having Epic back ends.
+
+GHC's run-time system~\cite{stg, evalpush}, ABC
+machine~\cite{abc-machine} and why we don't just use one of them
+(no useful interface, imposes constraints on the type system).
+Some influence from GRIN~\cite{grin-project}.
+
+Lazy virtual machine~\cite{lvm}. C-~~\cite{c--} and LLVM~\cite{llvm}
+as possible code generation strategies. Supercompilation for
+optimisations~\cite{mitchell-super}.
 
 \section{Conclusion}
 

Papers/Epic/epic.tex

@@ -1,4 +1,4 @@
-\documentclass{article}
+\documentclass[preprint]{sigplanconf}
 %\documentclass[orivec,dvips,10pt]{llncs}
 
 \usepackage[draft]{comments}
@@ -49,17 +49,36 @@
 
 \begin{document}
 
-\title{Epic --- a Generic Functional Compiler}
-\author{Edwin Brady}
+\title{Epic --- a Generic Back End for Functional Programming Languages}
+%\author{Edwin Brady}
+
+\authorinfo{Edwin C. Brady}
+{School of Computer Science, 
+University of St Andrews, St Andrews, Scotland.}
+{Email: eb@cs.st-andrews.ac.uk}
+
 
 \maketitle
 
 \begin{abstract}
-Epic is a minimal, compiled functional language, intended as a
-flexible target language for high level functional languages. It is
-independent of the source language's type system, supports eager or
-lazy evaluation, and has a range of primitive types and a lightweight
-foreign function interface.
+Compilers for functional languages, whether strict or non-strict,
+typed or untyped, need to handle many of the same problems, for
+example thunks, lambda lifting, optimisation, garbage collection, and
+system interaction.  Although implementation techniques are by now
+well understood, it remains difficult for a new functional language to
+exploit these techniques without either implementing a compiler from
+scratch, or attempting fit the new language around another existing
+compiler.
+
+Epic is a compiled functional language which exposes functional
+compilation techniques to a language implementor. It has both a
+concrete syntax and a Haskell API. It is independent of a source
+language's type system and semantics, supports eager or lazy
+evaluation, and has a range of primitive types and a lightweight
+foreign function interface. In this paper we describe Epic and
+demonstrate its flexibility by applying it to two very different
+functional languages: a dynamically typed turtle graphics language and
+a dependently typed lambda calculus.
 
 \end{abstract}
 

Papers/Epic/intro.tex

@@ -6,8 +6,40 @@ \section{Introduction}
 language. Either too low level, or an interface isn't exposed, or
 where an interface is exposed, there are constraints on the type
 system. So things like Agda~\cite{norell-thesis} have resorted to
-generating Haskell with unsafeCoerce.
+generating Haskell with unsafeCoerce. This works but we can't expect
+GHC optimisations without working very hard, are limited to GHC's
+choice of evaluation order, and could throw away useful information
+gained from the type system.
 
 Epic originally written for Epigram~\cite{levitation} (the name is
 short for ``\textbf{Epi}gram \textbf{C}ompiler''). Now used by
 Idris~\cite{idris-plpv}, also as an experimental back end for Agda.
+
+\subsection{Features and non-features}
+
+Epic will handle the following:
+
+\begin{itemize}
+\item Managing closures and thunks
+\item Lambda lifting
+\item Some optimisations (currently inlining, a supercompiler is planned)
+\item Marshaling values to and from foreign functions
+\item Garbage collection
+\item Name choices (optionally)
+\end{itemize}
+
+\noindent
+Epic will not do the following, by design:
+
+\begin{itemize}
+\item Type checking (no assumptions are made about the type system of
+  the high level language being compiled)
+\end{itemize}
+
+Epic has few high level language features, but some additions will be
+considered which will not compromise the simplicity of the core
+language. For example, a pattern matching compiler is planned, and
+primitives for parallel execution.
+
+Also lacking, but entirely possible to add later (with some care) are
+unboxed types.

Papers/Epic/language.tex

@@ -45,7 +45,7 @@ \subsection{Definitions}
  & \mid & \TC{Ptr} & \mbox{(Foreign pointers)} \\
  & \mid & \TC{Fun} & \mbox{(Any function type)} \\
  & \mid & \TC{Data} & \mbox{(Any data type)} \\
- & \mid & \TC{Any} & \mbox{(Unchecked polymorphic type)} \\
+ & \mid & \TC{Any} & \mbox{(Polymorphic type)} \\
 \end{array}
 \medskip
 \\

Papers/Epic/literature.bib

@@ -1,3 +1,22 @@
+@inproceedings{mitchell-super,
+ author = {Mitchell, Neil},
+ title = {Rethinking supercompilation},
+ booktitle = {Proceedings of the 15th ACM SIGPLAN international conference on Functional programming},
+ series = {ICFP '10},
+ year = {2010},
+ isbn = {978-1-60558-794-3},
+ location = {Baltimore, Maryland, USA},
+ pages = {309--320},
+ numpages = {12},
+ url = {http://doi.acm.org/10.1145/1863543.1863588},
+ doi = {http://doi.acm.org/10.1145/1863543.1863588},
+ acmid = {1863588},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+ keywords = {haskell, optimisation, supercompilation},
+} 
+
+
 @inproceedings{idris-plpv,
   author = {Edwin Brady},
   title = {Idris --- Systems Programming Meets Dependent Types},