Q: Forcing repeated evaluation

[Jan Kybic]

> I still think it's a real problem though. With Haskell as it is at the
> moment there seems to be no alternative to these ugly (and unreliable)
> hacks. Clean allows programmers to distinguish between constants and
> "functions" with zero arguments. Couldn't Haskell be modified to do
> the same?


I completely agree that it is a problem for real world programs. 
As for the solution, 
how to hint to the compiler that a certain value should be
evaluated as soon as possible, other value as needed, and still other
should be reevaluated everytime it is used, there are many
possibilities. This includes Strategies, strictness annotations,
compiler pragmas.

Those hints should not affect the result of the
computation, only the way the result is computed, therefore they do
not necessarily need to be part of the language but it would certainly
be easier to use if they were. Maybe in some years when the compilers
get very very clever, we will not need to give those hints and an
optimal code will be produced anyway. But we are not yet there.

My limited experience comes from implementing a large numerically
oriented program with complicated data structures in Haskell. I found
that the first prototype can be developed quickly and the language is
very expressive and safe at the safe time, which is a rare quality.
On the other hand, the resulting code in inefficient and scales very
poorly. While the first prototype could be used to handle problems of
small sizes, it quickly used up all available memory when applied to
bigger problems. A strictness annotation was essential to get it run
at more acceptable speed and to use less memory.  Another set of
annotations would be very helpfull in indicating what we want to
recalculate because we cannot afford to cache it.  I solved the
problem using some hacks in a very crude way but I am still looking
for a better solution.  (By the way, this this could be done
automatically - when the real time system runs out of memory, it could
simply delete some cached values, as they can almost always be
recalculated.)

Cheers,
        Jan

-- 
-------------------------------------------------------------------------
Jan Kybic <kybic@ieee.org>      Odyssee, INRIA, Sophia-Antipolis, France
       or <Jan.Kybic@sophia.inria.fr>,tel. work +33 492 38 7589, fax 7845
             http://www-sop.inria.fr/odyssee/team/Jan.Kybic/index.en.html