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
RE: [Caml-list] laziness
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-09-05 (05:47)
From: skaller <skaller@u...>
Subject: RE: [Caml-list] laziness
On Sun, 2004-09-05 at 11:07, Jason Smith wrote:

> >Must they be evaluated before the function is called?
> If O'Caml follows the usual eager order semantics then evaluation is AOR or 
> Applicative order redection. (Which is what I use in Mondrian).
> There are several locations where we may attempt to reduce this overhead.

Let me rephrase the question then. Suppose you wanted to
reduce the overhead "almost all the time". 
You can't do this if you specify the usual eager semantics.

So the question is: what changes to the semantic specification
would allow the optimisations?

For example: for 'simple' functions, it makes no difference
if evaluation is eager or lazy, so  the optimiser can choose
to evaluate lazily if it is possible the result will not
be used, or eagerly if it is used many times.

Many functions programmers write will have this property.

In a language where functions could have side effects,
clearly you'd have to either make some statement about
when and if the side effects occur, or simply
exclude such a function from the optimisation.

OTOH in Haskell I would guess there are only two properties
which would prevent an arbitrary evaluation time: if the
function could fail, or if it could fail to terminate.
So if the function is pure, total, and terminating,
there's no reason to specify when, if, or how many
times it is executed.

So you could, for example, simply allow the programmer
to state a function is 'nice' to allow the optimiser
maximum freedom (and on the programmers head it will
be if they lied :)

I'm not recommending this -- just giving an example
of one way one might try to get around what seems
to be a vast overconstraint for many functions
in languages that mandate some rigid mix of
eager/lazy semantics (and then try to optimise
the result preserving the semantics).

What would give the optimiser more freedom,
without sacrificing the *ability* to use eager
or lazy semantics when it is actually necessary

John Skaller,
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: