RE: [Caml-list] laziness

[skaller <skaller@users.sourceforge.net>]

On Mon, 2004-09-06 at 22:17, Jason Smith wrote:

> I'm not sure i follow you here. How can you *not* use something? 

Like this:

	let f x y  = x in
	f 1 (2/0)

Well y isn't used in the function. If you rewrite it like
this (eagerly):

	x = 1
	y = (2/0)
	x

then you divide by zero, but if you rewrite it like this (lazily):

	1

then (2/0) isn't used. 

> Um, ok so ur depositing debug statements in code to check if the expression is 
> still there.  I still fail to see why u can't just *look* at your code and see 
> if ur using the value or not. 

You can certainly try to do that, but it may be difficult.
If you have a function f with argument a, and an application
(f a) is an argument of a function g, .... it isn't
so easy to determine that the final result of your program
actually depends on the value of a: the result of f applied
to a may be used by another application, but is its result used?

Well if you have a fully lazy language, you can actually do
an experiment which can positively say 'yes'.

> Can I get an example?

Hehe -- sure, download Felix and tell me if
the 7'th argument to the 23'rd function in
the module 'flx_inline' is 'used' :)

[Arggg .. no don't actually do that .. you're supposed
to just throw up your hands in horror and admit defeat :]

> True, well almost true. The compiler can determine even in a strict language 
> if the value is used or not, using strictness analysis. So you could put 
> debugging statements in an expression and expect to see them and then volla, 
> do not. 

AHA! Can you?? 

Consider this: you aren't using an argument,
so you optimise it away.

Then you change the function so the argument
is *conditionally* used -- but call it
so the condition is never satisfied.

OK, so you have a dumb analyser that
can't tell the condition is never satisfied so
it keeps the parameter -- and now
suddenly the argument is eagerly evaluated.

Problem is the argument was a division by zero.
And a change in the function encoding with
no impact on the result it returns suddenly
never even gets entered (the program crashes
before the function is called).

This won't happen with a lazy language I think.

I asked 'Can you??' above and really meant it:
I'm actually inlining and optimising things
in my compiler now and I'm just NOT sure what
I can get away with and what I can't.

However it seems to me at the moment,
'sloppy specification of evaluation order
tending to laziness' actually allows more
optimisation opportunties than either
fully eager or  lazy semantics. The problem 
is I don't know if you can still write
enough useful deterministic programs with
sloppy semantics or not..?

[Felix doesn't allow side effects in functions
BUT procedures can modify variables so
the result of a function can vary depending
on when it is called compared to any procedures
hanging around ..]

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners