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 ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
