On Sun, Sep 05, 2004 at 01:07:48PM +1200, Jason Smith wrote:
> There are several locations where we may attempt to reduce this overhead.
>
> Strictness analysis: Determines usuing some form of abstract
> reduction semantics weather the argument is "strict" in the
> function, i.e. that it will be used at all. If it isn't then there
> is no need to reduce it. The problem with this is that in O'Caml u
> once again have side-effect's raise there ugly head. This means that
> even if the argument is not used in the function, the results of
> evaluating the argument which uses side-effects is. So you may have
> to analyse the argument itself and see if it uses any reference
> semantics.

One thing that worries me about laziness.

Doesn't laziness often indicate a bug in the code?  ie.  You've
written an expression in the program, but that expression is never
used.  This is dead code, right?  Hence a bug?

The only thing I can think of which countradicts this case is the
common Haskell example of the "infinite" list:

  numbersFrom n = n : numbersFrom (n+1)
  squares = map (^2) (numbersFrom 1)
  take 10 squares

But in a sense this contains dead code too.  You've written down your
desire to construct all the squares, and then later you change your
mind and take only the first 10.  In OCaml you'd write this correctly
as something like:

  List.map (fun x -> x * x) (range 1 10)

(Sorry if this appears like a troll, but actually I'm genuinely
interested in whether laziness is useful, or indicates a bug).

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
MONOLITH is an advanced framework for writing web applications in C, easier
than using Perl & Java, much faster and smaller, reusable widget-based arch,
database-backed, discussion, chat, calendaring:
http://www.annexia.org/freeware/monolith/