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@porg.es> wrote:
I believe there might be an elegant solution for this using the `Last` monoid