Browse files

Merge branch 'master' of

  • Loading branch information...
2 parents ce5fb12 + f4d93d3 commit acc16c1aea23113a885156dea1b3e3423e04a1fa Edwin Brady committed Dec 19, 2010
Showing with 99 additions and 11 deletions.
  1. +11 −0 Papers/Epic/conclusions.tex
  2. +27 −8 Papers/Epic/epic.tex
  3. +7 −0 Papers/Epic/example.tex
  4. +33 −1 Papers/Epic/intro.tex
  5. +2 −2 Papers/Epic/language.tex
  6. +19 −0 Papers/Epic/literature.bib
@@ -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
@@ -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.
@@ -0,0 +1,7 @@
+\section{Example High Level Languages}
+% Two different examples. Perhaps:
+% * a LOGO like language (foreign functions, graphics, dynamic types?)
+% * dependent types with natelim (e.g. adder)
+[Give high level translation, rather than concrete Haskell]
@@ -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.
@@ -21,7 +21,7 @@ \subsection{Definitions}
& \mid & \RW{if}\:\vt\:\RW{then}\:\vt\:\RW{else}\:\vt & \mbox{(Conditional)}\\
& \mid & \RW{case}\:\vt\:\RW{of}\:\vec{\VV{alt}} & \mbox{(Case expressions)}\\
& \mid & \RW{lazy}(\vt) & \mbox{(Lazy evaluation)} \\
-& \mid & \RW{effect}(\vt) & \mbox{(Evaluate an effectful evaluation)} \\
+& \mid & \RW{effect}(\vt) & \mbox{(Evaluate an effectful term)} \\
& \mid & \RW{while}(\vt,\vt) & \mbox{(While loops)} \\
& \mid & \RW{foreign}\:\vT\:\VV{str}\:\vec{(\vt\Hab\vT)} & \mbox{(Foreign call)} \\
& \mid & \vi \mid \vf \mid \vc \mid \vb \mid \VV{str} & \mbox{(Constants)} \\
@@ -56,7 +56,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)} \\
@@ -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 acc16c1

Please sign in to comment.