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

[Thomas Davie]

> 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'm not sure that `lots of people think that the semantics are fuzzy'  
is a good reason to change the semantics to be as such.  I would  
assert that the more rigid and tidy you make the semantics, the  
easier it becomes to prove nice properties etc. and from what I've  
seen, Haskell's semantics are already just a tiny bit too `fuzzy' to  
do this kind of thing.


>> [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.
>
Agreed - I was very much enjoying watching this thread.

Bobb