[Haskell-cafe] Re: Understanding tail recursion and trees

Daniil Elovkov daniil.elovkov at googlemail.com
Thu May 1 16:10:50 EDT 2008


Felipe Lessa wrote:
> On Thu, May 1, 2008 at 9:44 AM, Felipe Lessa <felipe.lessa at gmail.com> wrote:
>> On Thu, May 1, 2008 at 9:32 AM, Edsko de Vries <devriese at cs.tcd.ie> wrote:
>>  >  So then the question becomes: what *is* the best way to write this function?
>>
>>  I guess it would be simpler to have the counter on the data type and a
>>  smart branch constructor:
> 
> Under more careful analysis, it seems I just moved the stack overflow
> from the counter function to the generator =). Modifying the data type
> to
> 
>> data Tree = Leaf Integer | Branch !Integer Tree Tree
> 
> also won't work in this example (although it seems to fail earlier).
> However, I'd expect the data type above to work nicely with most real
> applications (that doesn't construct the entire tree in one go), such
> as Data.Map[1].
> 
> But the answer to your original question really seems to be using an
> explicit stack created in the heap. This technique is used in Data.Map
> in a certain case[2] and, although has received a lot of attention on
> a thread that sparked some time ago (I think it was [3]) for being
> merely a workaround over the limited stack, it seems to me it's a
> compulsory workaround for the time being when working with problems
> like yours.
> 

I think that consuming heap instead of stack is the best we can do.

I may be wrong, but it seems to be more or less impossible to traverse a 
tree in constant memory. Well, if the tree structure doesn't have back 
links (apart from left, right).

The thing is we have to remember nodes to return and remember if we went 
to the left or to the right. The left or right biased tree is just a 
list-like structure, where we don't have to remember anything, we can 
just proceed. That's why it easy to traverse them in constant memory.

Maybe, in a C program we could traverse a tree without back links in 
constant memory by XORing pointers and left-right booleans. That would 
employ the property of xor that (a xor b) xor a = b. But I'm not sure.

Well, anyway, that's not about Haskell.


More information about the Haskell-Cafe mailing list