Add malloc_ to Epic interface

Epic/Epic.lhs

@@ -21,6 +21,7 @@
 >                  foreign_, foreignL_, foreignConst_, foreignConstL_,
 >                  let_, letN_, update_, op_,
 >                  str, int, float, char, bool, unit_, (!.), fn, ref, (+>),
+>                  malloc_,
 >                  -- * Types
 >                  Type, tyInt, tyChar, tyBool, tyFloat, tyString,
 >                  tyPtr, tyUnit, tyAny, tyC,
@@ -262,6 +263,15 @@ Remaining expression constructs
 > foreignConst_ t str = term $ ForeignCall t str []
 > foreignConstL_ t str = term $ LazyForeignCall t str []
 
+> -- | Evaluate an expression under manually allocated memory. Creates a pool
+> -- of memory. All allocation is from this pool, and there is no garbage
+> -- collection. The pool is freed after evaluation.
+> malloc_ :: (EpicExpr a, EpicExpr b) => 
+>               a -- ^ Size of block to allocate
+>            -> b -- ^ Expression to evaluate
+>            -> Term
+> malloc_ = exp2 (WithMem FixedPool)
+
  mkCon :: Int -> [Term] -> Term
  mkCon tag args = do args' <- mapM expr args
                      return (Con tag args')

Papers/Epic/implementation.tex

@@ -0,0 +1,16 @@
+\section{Implementation}
+
+How it's implemented is not really important to the user --- a
+compiler can target Epic without knowing, and we could drop in a new
+back end at any time in principle.
+
+There is currently one back end, but more are planned. Compiled via
+C. Garbage collection with Boehm~\cite{boehm-gc},
+\texttt{\%memory}. (Note that a non-moving collector makes things
+easier for foreign functions, but may not be the best choice in the
+long run).
+
+Later plans: compile via LLVM, allow plug in garbage collectors
+(important for embedded systems, device drivers, operating system
+services, for example).
+