Description
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_iterator
s 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.