Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Help me find this pdf
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-10-18 (12:46)
From: Jacques Garrigue <garrigue@m...>
Subject: Re: [Caml-list] Help me find this pdf
From: Jon Harrop <>
> On Thursday 18 October 2007 10:52:26 Tom wrote:
> > Not long ago I was searching the Internet on the topic "combining eager and
> > lazy evaluation", and have run over a paper which I obviously dismissed as
> > "not interesting enough", yet now I have realized that it could indeed be
> > useful, but am unable to find it.
> >
> > I know it was talking about a useful primitive, I do not know how exactly
> > it was named, which checked whether values passed as arguments to functions
> > were lazy (blocks to be evaluated) or eager (already evaluated), and using
> > it some functions, e.g. map (this example was present in the paper) could
> > be implemented to be both eager and lazy at the same time, depending on the
> > arguments.
> >
> > Does anyone recognize this description?
> Scala can do something similar by controlling evaluation simply by altering 
> the signature. However, I've reviewed Haskell recently and I think complete 
> laziness is more of a hindrance than a benefit. The only think I'd like to 
> see added to eager FPLs is the ability to pattern match over lazy values, 
> forcing them only when necessary.

What! You want Caml V3.1 (released in 1991 IIRC)!
I remember writing a lazy prolog interpreter using this feature.

Lazyness in ocaml works too, but it's more verbose.

Actually Caml 3.1 had only lazy fields in records. To be complete, one
would like to mark as lazy any part of a datatype, like you could mark
as mutable fields of a constructor in later versions of caml-light.

But then I don't use lazyness in data structures very often. 

Jacques Garrigue