"Bayley, Alistair"
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