can it work (or be made to work) with closure iterators?
timotheecour opened this issue · comments
looks like it now works with inline iterators (cf #20), but how about with closure iterators?
@timotheecour what about them? What is the advantage?
from the docs:
An inline iterator is an iterator that's always inlined by the compiler leading to zero overhead for the abstraction, but may result in a heavy increase in code size. Inline iterators are second class citizens; They can be passed as parameters only to other inlining code facilities like templates, macros and other inline iterators.
In contrast to that, a closure iterator can be passed around more freely
see also: https://forum.nim-lang.org/t/2027 Iterator as argument of iterator
OK - understood - the thing is: do we need to pass it around?
Zero-functional is "just" a code generator. I fail to see the benefit in contrast of defining your own proc.
There are two points:
- how to name the child? Don't know - createClosure() - instead of createIter() or maybe add a parameter
createIter(closure=false)- and when callingcreateIter(true)the iterator would be closure iterator - is it possible at all? I don't know how to apply the closure pragma during the macro processing. Does something like this work or is it restricted?
Try to give me a working example where you need the closure iterator - not some theoretical foo-bar-stuff - try to use normal loops instead of zero_functional calls (e.g. by unpacking your code with the -->> operator).
If you convince me that this is what we need, I'll happily invest the time, but currently I am not convinced. Otherwise: this is open-source: make a pull request. Your call
related: #36 (comment) which has a working example
yeah - and still not convinced by that foo-bar-example
For that code to work you could also write
s() --> foreach(echo it)and this would not even hide the fact that you're only echoing the contents of the iterator.
But I see the point that maybe - maybe it would be nice to chain iterator calls even though this particular example does not make too much sense. OK - I will have a look, but if I run into too many problems I will give up much sooner than I did before when implementing other features!
yes it was a simplified example. The bigger point is code reuse: I'd like to be able to reuse procs that take iterators and are not custom designed around zero-functional (eg from standard library or other nimble packages). Thanks for being open to this idea!
OK - I think I close this one now as the further discussion was done in #36 and closure iterators are supported now.