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

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

> I agree. I once tried to port some haskell combinators [1] to ocaml. 
> However I had to stop since using them meant cluttering your code with 
> (lazy e) and lead to unreadable code.

Yes using lazy all over the place is too much!

That's why we had once in Caml some implicit way to denote lazy
expressions, such as when applying a constructor or building a
record. Lazy record fields or lazy constructors had to be declared
when defining the type they belongs to; then their usage was
implicitely lazy. For example, lazy integer lists were defined as:

type llist = {lazy head : int; lazy tail : llist};;

Now, {head = expr_head; tail = expr_tail} was automatically compiled
as {head = lazy (expr_head); tail = lazy (expr_tail)} (with trivial
optimisations if the lazy expressions are simple enough ({head = 1;
...} would build any lazy thunk)). Also an addition to the pattern
matching algorithm allowed automatic forcing of lazy parts of data
structures. This technic leads to simple and readable lazy programs.

> A more lightweight notation would be needed in order to do real lazy 
> programming in ocaml. At that time I wondered if specifiying the 
> lazyness when one defines the function and not when one uses it would 
> be a problem (I mean a technical problem, not an ideological one).
> For example if one defines
> 
> let f (lazy x) = ...
> 
> then the application f (x + y) would implicitely mean f (lazy (x + y)). 

That's a good idea, if only it were compatible with higher-order
functionality (and modularity), which I don't know for sure.

In my mind, this idea would be a type-based transformation of the
source code. The typing rule for lazy function application would be:

|~ -: (f : 'a lazy -> 'b) (e : 'a)
----------------------------------  (lazy app)
           |~ -: (f e : 'b)

and the transformation rule on the type annotated abstract syntax
trees would be:

(f : 'a lazy -> b) (e : 'a) => (f : 'a lazy -> b) (lazy e : 'a lazy)

Interestingly enough, the typing rule implies that you not only can
omit the lazy keyword at application time: it would be mandatory to
omit it! Weel, not so bad, after all ...

This has to be precisely ruled out and the necessary proofs have to be
made, but I think it could work (including for higher-order
functional, map, fold, and so on). I mean, I don't see any trivial
counter-example that would ruin this scheme. Wao! If this rule
turned out to be usable, it would be a major improvement for lazy
evaluation in our favorite language.

> Alternatively something less intrusive than the keyword 'lazy' would be 
> good.
>
> Daniel
> 
> [1] <http://doi.acm.org/10.1145/944705.944727>

Right, but which one ?

Best regards,

Pierre Weis

INRIA, Projet Cristal, 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