Re: lazyness in ocaml (was : [Caml-list] kprintf with user formatters)

[Pierre Weis <pierre.weis@inria.fr>]

[...]
> But this looks very dangerous!

Yes: lazyness in the presence of side-effects is tricky. But don't
worry, that's not the introduction of this new rule that is dangerous,
it is the concept of lazy evaluation and more importantly the mixing
of lazy evaluation and strict evaluation that is difficult in the
presence of side effects.

> Its kind of like reference parameters in C++, which make
> it impossible to tell if  f(expr) can modifiy expr or not
> [without finding which 'f' it is and examining it]

I cannot understand that one. We have that in Caml already and we had
it from the very begining of Caml (1984). For instance, if I write

f (expr)

could you tell me ``if  f(expr) can modifiy expr or not [without
finding which 'f' it is and examining it]'' ?

To the best of my knowledge, the answer is no.

To the best of my knowledge, nobody never complained about that feature.

> > In the lazy case it would destroy an important identity:
> 
> f x <==> let x' = x in f x'
> 
> With your rule, the LHS might not evaluate x, whereas the RHS
> would.

Yes, that's exactly what we want: if (f e) is a lazy application you
don't know if e is evaluated or not. This is just what lazyness is
about !

Also, I didn't know that such an ``important identity'' stands for
Caml expressions. Except in the trivial case where ``x'' just denotes
a variable in the statment. In this case, the statment still holds with
the new rule :)

> Of course we already have that:
> 
> f x y <=/=> let x' = x in y' = y in f x' y'
> 
> since the RHS guarrantees x is evaluated before y,
> whilst it happens by chance in the current Ocaml implementation
> the reverse is true for the LHS.

So what? Is the ``important identity'' wrong after all, being wrong in
this case ? Or do you suggest to suppress currying in order to restore
the ``important identity'' ?

> So even if your rule is sound, it might not be a good idea
> because it breaks 'the substitution principle'.

There is nothing such as your ``substitution principle'' in Caml,
except if we restrict the language to truly trivial expressions (as
soon as expressions may incoporate basic operators such as the integer
addition your ``principle'' does not stand anymore).

> How about sugar:
> 
> \(expr) <==> lazy expr
> 
> Since arguments to be lazily evaluated are never variables,

Wait a minute: do you mean I cannot write f e, if e is just a variable?

If the answer is yes, your suggestion breaks something important (we
still want to apply a function to any expression of the suitable
type); if the answer is no then you would need to write f \x as you
now have to write f (lazy x) with the current compiler. Or you would
have to implement something really strange to handle f e differently
if the expression e is a variable or not.

Best regards,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


-------------------
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