Moved from #264:

@pchampin: Sorry to bother you with this again, but I ran into another edge-case. I was trying to implement my own version of reduce (just for the sake of learning). This is how I first tried:

def myreduce(func, items):
    match [first]::tail1 in items:
        match [second]::tail2 in tail1:
            return myreduce(func, [func(first, second)]::tail2)
        else:
            return first

but then I got the segfault bug :-(

I solved the problem like this (with your latest patches on recursive_iterator):

@recursive_iterator
def _myreduce(func, items):
    match [first]::tail1 in items:
        match [second]::tail2 in tail1:
            return _myreduce(func, [func(first, second)]::tail2)
        else:
            return [first]

def myreduce(func, items) = _myreduce(func, items)[0]

Note that the intermediate _myreduce function artificially returns a one-element list, in order to satisfy the requirement that recursive_iterators must return an iterable.

I think the issue here is that recursive_iterator plays two distinct roles:

optimizing recursive iterators, and
fixing the segfault bug.
Wouldn't it be possible to have a separate decorator just for fixing the segfault bug in recursive functions that do not return an iterator?

@evhub: @pchampin Interesting! I've never seen the segfault bug show up in that context before. It definitely does seem like a separate decorator for resolving the bug for non-iterator functions is necessary (probably something like @memoize, since @recursive_iterator is effectively iterator memoization behind the scenes). This definitely deserves its own issue--either you can raise another issue about this if you want, or I'll take care of it when I get back from work today.