Browse files

Tinkering with paper

  • Loading branch information...
1 parent ee20292 commit f4d93d3df7b852fa132892f24582828a0db36521 Edwin Brady committed Dec 19, 2010
Showing with 91 additions and 10 deletions.
  1. +11 −0 Papers/Epic/conclusions.tex
  2. +27 −8 Papers/Epic/epic.tex
  3. +33 −1 Papers/Epic/intro.tex
  4. +1 −1 Papers/Epic/language.tex
  5. +19 −0 Papers/Epic/literature.bib
11 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
35 Papers/Epic/epic.tex
@@ -1,4 +1,4 @@
@@ -49,17 +49,36 @@
-\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.}
-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
+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.
34 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:
+\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)
+Epic will not do the following, by design:
+\item Type checking (no assumptions are made about the type system of
+ the high level language being compiled)
+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.
2 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)} \\
19 Papers/Epic/literature.bib
@@ -1,3 +1,22 @@
+ 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 = {},
+ doi = {},
+ acmid = {1863588},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+ keywords = {haskell, optimisation, supercompilation},
author = {Edwin Brady},
title = {Idris --- Systems Programming Meets Dependent Types},

0 comments on commit f4d93d3

Please sign in to comment.