Re: [Factor-talk] Playing with python-like iterators (and efficiency of continuations)

[Joe G. <ar...@gm...>]

On Oct 31, 2009, at 6:32 PM, Paul Moore wrote:

> Looks interesting. Certainly, it's very similar to what I was thinking
> of, but some parts confuse me (I can't see how the "iterate" word
> works, for example - the "iterator" argument on the top of the stack
> doesn't make sense).

I wouldn't treat the code there as sacrosanct; it is in "extra", after  
all, and nothing appears to use it yet. But it looks like a good  
starting point for a proper cursor protocol rather than beginning from  
scratch.

The "iterate" word is glue to allow sequence combinators like "each"  
to be implemented in terms of cursor operations—it makes a cursor over  
a sequence and then calls the "iterator" quotation on the cursor (It's  
probably better called "iterate-sequence".) It's using Smalltalk jargon 
—a "cursor" points to a position in a stream (what Python, C++, and  
other languages call the iterator) and an "iterator" is a function  
that performs the iteration (such as each or map).

> The requirement of cursor-done? doesn't sit well with my generator
> function use case, though (as I explained in my reply to Dan, it
> implies the need to cache a value).


The protocol could be changed. Better would be to have cursor-advance  
return a flag indicating when the stream is exhausted, after which the  
cursor goes invalid. Using an exception to signal end of iteration is  
just crazy.

Generators are an obscure use case, and I wouldn't warp the cursor  
protocol to accommodate them. They get overused in Python because it's  
the only practical way to do some things in that language because of  
its lack of tail calls and practical anonymous code blocks. Factor has  
both, and those are better, more idiomatic, and more optimizable tools  
for what people try to make generators do in Python.

-Joe