[Haskell] Importance of precise lazy-evaluation semantics (was: line-based interactive program)

[Jean-Philippe Bernardy]

> >>My interaction depends on the (subtle order of) evaluation of a pure and
> >>total function?
> >>
> Pure, yes; total, no.
> 
> Many important things depend on order of evaluation in lazy programs:
> for example, whether they compute a well-defined value at all!   The
> interleaving of demand in the argument of a function with computational
> progress in its result seems a perfectly natural view of interaction in
> a lazy functional language.  This sort of interaction is what actually
> happens when your function applications are evaluated whether you
> exploit it or not.  I embrace it as part of lazy functional programming;
> you prefer an appeal to something extraneous.

It seems to me that this sort of thing is why haskell is difficult to
compile to efficient code. I have the impression that relaxed
semantics wouldn't hurt 99% of programs while make the compiler-writer
job easier. The only disadvantage is that tricks like the above one
wouldn't work any more.

Another point is, imho, most haskell programmers don't grasp the exact
lazyness semantics; they think of lazyness as "evaluation order is up
to the compiler", not the precise graph-reduction thing.

Hence, haskell would perhaps be better off with more "fuzzy"
semantics, since it would match the intuition of people, and allow
more optimized code. Those ideas have been explored before, if I'm
correct in the "optimistic evaluation" project, and Eager haskell.
Yet, I'm wondering what's the current opinion of the haskell "gurus"
on the subject.

> [I am conscious that we are using bandwidth on the main Haskell mailing
> list for this little discussion -- perhaps we are about done, but if not
> perhaps we should mail each other direct.]

The subject is very interesting to me, and I suspect many others, so feel free.


Cheers,
JP.

[1] Eager haskell
http://csg.csail.mit.edu/projects/?action=viewProject&projectID=5&projectGroup=Programming%20Languages

[2] Optimistic evaluation
http://www.cambridge.intel-research.net/~rennals/icfp2003.pdf