[Haskell-cafe] following up on space leak

[Uwe Hollerbach]

Hi, George, thanks for the pointer, it led me to some interesting
reading. Alas, the problem which it solves was already solved, and the
unsolved problem didn't yield any further...

At this point, I've concluded that my interpreter just simply isn't
tail-recursive enough: in the Collatz test case I had originally
looked at and mentioned, it seems that no matter what I do the memory
usage stays the same. Initially, a significant portion of the usage
showed up as one particular function in the interpreter which applies
binary numerical operators to a list of numbers. It's a moderately
complex function, as it deals with any number of operands, and it
takes care of type conversions as well: if I add two integers, I want
the result to be an integer; if I add in a float, the result will be a
float, etc.

In my particular usage in this test case, it was only getting used to
increment an integer; so I simplified that, I added an "incr" function
to my interpreter and called that instead... now exactly the same
amount of memory usage shows up in the cost center labeled "incr" as
was previously being used in the more-complex numeric-binary-operator
function. I've cut down the interpreter to about a quarter of its
original size, now I've got a version that really is only useful for
running this Collatz test case, and... it uses exactly the same amount
of memory as before.

The last thing I tried before giving up was to try and make a
more-strict bind operator, I think I wrote that as

    (!>=) !m !k = m >>= k

with appropriate -XBangPatterns added to the compiler options. It
passed all the self-tests for the interpreter, so I'm pretty sure I
didn't do anything wrong, but it made no difference to the memory
usage. So for now I've shelved that problem, I'm looking instead at
adding proper continuations to the interpreter.

Uwe

On 7/7/09, George Pollard <porges at porg.es> wrote:
> I believe there might be an elegant solution for this using the `Last`
> monoid
>