On 12/05/2014 02:16 PM, Stefan Monnier wrote:
>> I think we could do so, though, apart from the definition, our packages
>> seem quite disjoint.
> 
> I prefer to look at it as "complementary".
> 
>> Anyway, it would be good if Daniel's generators would then be valid
>> iterators in terms of the new iterator.el.
> 
> Indeed, that would be nice.  Can you try and work that out?

Assuming both packages are suitable for inclusion into core, we can definitely make them work together. I'd still very much like to use nonlocal control flow instead of a sentinel for enumeration termination, however.  

That aside, I'm not sure I agree with your namespace preferences. `yield' is fundamentally a lexically-scoped macro. Making it defer to some prior definition makes no sense, since any code that can see this macro is already written with generators in mind.

I'd also strongly prefer using `next' as the iter-get function. If we're going to make the iteration protocol a core part of the environment, it deserves a prominent place in the global namespace. Using `funcall' is inadequate: first, it doesn't signal iteration in calling code, which can lead to confusion, and second, `funcall' doesn't work if we want to extent `next' to support things like lists, for which `next' would be equivalent to `pop'. AFAICT, nothing is already squatting on `next', so binding the symbol's function slot would be harmless for a compatibility perspective.

I'd also prefer using `iterating' as the cl-loop keyword. Because the keyword is only active in the lexical scope of a cl-loop construct, there's an even lower risk of collision, and the word "iterating" is exactly the right thing in the cl-loop language: (cl-loop for x iterating y collect x) reads very well.