[m-dev.] Lazy Evaluation

Fergus Henderson fjh at cs.mu.OZ.AU
Sat Mar 13 20:59:33 AEDT 1999


On 12-Mar-1999, Gustavo A. Ospina <gos at info.fundp.ac.be> wrote:
> 
> I read in your mailing lists about the Mercury Team have developed one
> module to handle lazy evaluation. I need to know what is the actual state
> of this module

The module is currently undergoing review, with the current plan being to
incorporate it in the `extras' distribution with future versions of Mercury.

So far it hasn't had much testing, but worked fine (first time ;-)
for the one test case that I have tried so far.

It also works fine with Mercury 0.8.1, so you don't need to get the latest
Mercury distribution, it's enough to just get the modules in question.

The current implementation is not very efficient.

> and what is the semantics you used to implements it.

I've added some stuff to the documentation for the `lazy' module
explaining the declarative and operational semantics.

Note that it's just a library module, and it doesn't have any
effects on the overall semantic model for Mercury, which is still
the one outlined in the semantics chapter of the Mercury language
reference manual.  The operational semantics used is still the
standard (i.e. typically eager) Mercury evaluation; it achieves
the same *effect* as lazy evaluation by passing lambda expressions.

> Also if you have bibliography I would like to know it.

The following papers explain the basic trick of simulating call-by-name
using call-by-value.

[1] G.D.Plotkin.  Call-by-name, call-by-value and the lambda-calculus.
Theoretical Computer Science, 1(2), pages 125-159, 1975.

[2] John Hatcliff and Olivier Danvy.  Thunks and the lambda-calculus
(extended version).  Journal of Functional Programming.  March 1997.
<http://www.brics.dk/RS/97/7/index.html>.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.



More information about the developers mailing list