[TYPES] Combining lazy and eager evaluation of terms

Jan-Willem Maessen - Sun Labs East Janwillem.Maessen at Sun.COM
Wed Aug 25 11:16:55 EDT 2004


Tim Sweeney wrote:
> In an attempt to combine some of the benefits of lazy and eager
> evaluation, I have implemented a language with an evaluation strategy
> which is strict with respect to divergence, but performs lazy evaluation
> on certain intermediate subterms to allow a more expressive use of
> recursion.

Two different projects have implemented semantically-correct Haskell 
with eager evaluation.  The first of these was my Ph.D. thesis, Eager 
Haskell:
   http://csg.lcs.mit.edu/~earwig/thesis.html
This page also includes a link to the short paper I prepared on my 
implementation for the 2002 Haskell Workshop.

The second implementation was based on GHC, and was done by Robert 
Ennals at Cambridge University.  He and Simon Peyton Jones published 
the paper "Optimistic evaluation: an adaptive evaluation strategy for 
non-strict programs" in ICFP 2003:
   http://doi.acm.org/10.1145/944705.944731

In both cases we evaluate Haskell using resource-bounded eager 
evaluation: run eagerly until you run into something uncomputed (in 
which case create a thunk) or until some resource bound is exceeded 
(in which case create a thunk).  Force thunks as necessary during 
eager evaluation.

The difference between our two schemes was that mine used a static 
strategy which didn't differentiate between suspension sites.  This 
meant that (say) each unfolding of an infinite list would alwys run 
for a large number of steps before reaching a new resource bound. 
Rob's work dynamically modified call sites which caused resource 
bounds to be exceeded, so that particular problem areas were throttled 
explicitly.  Both techniques do well for code that is mostly eager; 
it's only when lazy infinite (or extremely large) data structures are 
involved that things get tricky.  I hold out hope that a slightly 
better set of static heuristics would avoid the problems with my 
scheme, but I've moved on to entirely new problems these days.

Absent the time bounds, it sounds like our work is very similar to the 
mechanisms you have been exploring.  The time and space bounds make 
things a bit more complicated than I would at first have imagined, but 
yield a semantics which is entirely equivalent to that of a lazy 
implementation.

-Jan-Willem Maessen
  jmaessen at alum.mit.edu



More information about the Types-list mailing list