"Bayley, Alistair" writes:

...

...

Lazy evaluation is an implementation technique which satisfies non-strict semantics, but it is not the only technique which does this.

where can I find information about non-lazy implementation of non-strict languages?

Remember that laziness = non-strictness + sharing. Thus, one valid but non-lazy implementation strategy for Haskell would be to avoid sharing. E.g. in let a = something in a+a you could evaluate 'a' twice. That might seem silly, because it wastes work. But there are potential benefits: * A multi-processor parallel implementation would not need to put locks around computation that is already underway. Locks can be expensive and tricky to get right - just doing the computation twice might be cheaper. * If the shared value is large and persists for a long time but is only used infrequently, it might be considered a space leak. If the heap is nearly full, it could be cheaper to throw the value away immediately and recalculate it each time it is needed. A reduction strategy that /always/ avoided sharing would be unlikely to have great performance, but one that was selective about sharing (based on either fancy analysis, or empirical profiling) could possibly be useful. Regards, Malcolm

On Jul 18, 2005, at 10:19 AM, Bayley, Alistair wrote:

...

From: Jerzy Karczmarczuk [mailto:karczma@info.unicaen.fr]

Bernard Pope wrote:

...

I'll be a little bit pedantic here. Haskell, the language definition, does not prescribe lazy evaluation. It says that the language is non-strict. Lazy evaluation is an implementation technique which satisfies non-strict semantics, but it is not the only technique which does this.

This pedantry is renewed periodically.

It is a pity that nobody ever writes anything about that other methods of implementation of non-strictness, nor about the languages which use those methods.

I believe it might do some good to people who learn functional programming in general, and Haskell in particular. Any takers?

Not a taker (yet - where can I find information about non-lazy implementation of non-strict languages? From Google so far: speculative evaluation (Eager Haskell), call-by-name vs call-by-need.)

Wikipedia frustratingly hints that "other evaluation strategies are possible", but that's all it says: http://en.wikipedia.org/wiki/Non-strict_programming_language

I volunteered to Jerzy privately, but I'm still not clear what it is people want to know. That'd be more useful than, say, plugging my own research. :-) -Jan-Willem Maessen

Alistair.

----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe