🚀 go-pugleaf

Steven J Bevan writes:

| This works well, and keeps the usage down to under 2Mb for the input
| that previously ran out of heap.  However, there are a couple of
| things that bother me about this :-
| 
| 1. The extra amount of work that has to be done in "forcing" the store.
|    This bumps up the runtime.

Hmm ... but not by much.

| 2. A simple, one-liner using higher order functions has turned into a
|    10 line tail recursive loop.  Now being a Schemer at heart, I have
|    no particular problem with this, but it does seem to go against the
|    whole idea of "higher order functions are good" which most fp books
|    espouse.

I have a couple of comments on this.  Firstly, the problem
is you are getting 000's of thunks.  The problem is *not*
the use of a higher-order function.  Even if you unfolded the
definition of "foldl" at the parameterisation shown, the program would
behave the same.

Secondly, a few minutes of investigation and a few changed lines
made a massive difference to the usability of the program. 
In my book this is a very small price to pay for the
convenience of a language as expressive as Haskell.  I believe
a few (say five at most) strategically placed hyperstrictnesses (so to speak)
can make a big difference to the space behaviour of programs 
tens of thousands of lines long.  Using a heap-profiling
compiler, it is easy to spot the functions filling the heap up
with thunks.

For this reason, I believe the Haskell committee should
consider the provision of two built-in functions:

   hyperstrict, whnf :: Eq a => a -> b -> b

both of which evaluate their first argument (fully or to whnf)
and return the second.  We can simulate this at the moment using
Haskell 1.2, but it might be more efficient if compilers could
regard these as primitive.

Jules