🚀 go-pugleaf

In article <1992Oct8.124228.10449@kth.se> kff@dentex.tds.kth.se (Karl-Filip Faxen) writes:
>In article <TMB.92Oct7181835@arolla.idiap.ch>, tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
>
>|> (in fact, not having this
>|> control over evaluation and resources is precisely why I don't like
>|> lazy evaluation).
>
>And it is precisely why I like it. I believe that the "creative" part
>of an algorithm is specifying the data dependencies. Then a good
>compiler should be able to come up with an evaluation order that is at
>least as efficient in terms of resource (eg memory) consumption,
>locality and (when the machine can take advantage of it) parallelism,
>as any I could come up with myself with a reasonable amount of work.

Well, then don't hold your breath for "good compilers". Decisions like
these are input data dependent and/or require a significant
understanding of the meaning of the algorithm you are implementing. A
compiler has neither, nor can it.

Based on runtime/profiling information, some optimizations like these
can be carried out, but both the overhead and the effort involved for
the programmer are non-trivial (in particular, there are many cases in
which I don't even run the same program more than once).  I find it
easier to state in advance what I know about my algorithm.

   It may be that annotations are a good idea, separating data dependencies
   from resource management decisions.

Well, yes. And taking advantage of eager evaluation for these kinds of
"annotations" seems to be quite natural. Why change this?

					Thomas.