[Haskell-cafe] Strict and non-strict vs eager and lazy

Malcolm Wallace Malcolm.Wallace at cs.york.ac.uk
Mon Jul 18 11:41:58 EDT 2005

"Bayley, Alistair" <Alistair_Bayley at ldn.invesco.com> 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

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.


More information about the Haskell-Cafe mailing list