
Stjepan Rajko wrote:
On Tue, Jul 15, 2008 at 7:53 PM, Joel de Guzman <joel@boost-consulting.com> wrote:
1) The concept of an infinite-sequence.
I'm not quite happy that all sequences has a finite size. Perhaps we can return something like fusion::infinite_size
That would be really nice! I will make the Size template parameter a typename, so fusion::infinite_size can be specified if/when it becomes supported. I think the implementation will only need to change its behavior related to the end iterator. That way, we can have both finite and infinite lazy_sequences.
If this is possible, then we should have a new infinite-sequence concept. I wonder where and how that will fit in the fusion concepts hierarchy.
It seems orthogonal to other Sequence concepts... Maybe the Sequence concept should have the "size is an integral constant" requirement pulled out of it, and then have FiniteSequence and InfiniteSequence concepts that refine that?
Perhaps we need not add new concepts if we simply relax the size requirement. We simply state that a Forward Sequence may be finite or infinite, and add an /fusion::inf/ type representing infinity. The library has to be tweaked though for code (using size) that may break with this new size representation. This is a potentially breaking change, so the user must also be warned (docs).
2) If this is not possible, then the interface should at least be compatible with the at_c and at interfaces:
make_lazy_sequence<MPL-N>(f); make_lazy_sequence_c<N>(f);
and of course, its result_of counterparts.
OK
Then, oh well... docs. Where should we put this? views, I guess.
I had thought of it as a container, but I think you are right - should be a view. It is conceptually similar to single_view (in that it is not a view into a Sequence), perhaps described as "a view into the return values of a unary callabale object or function".
That's good. Can be better though, me thinks.
That maybe suggests changing the name to something like "callable_view" (perhaps there is a better variant that doesn't suggest that the view is callable).
Yeah, I agree. All views are inherently "lazy" anyway. So it's not a good name. More suggestions, anyone, please? functional_view? computed_view?
Also - do you think we should support both unary and nullary callable entities (in the current naming convention, have both something like "lazy_sequence" and "uniform_lazy_sequence", or in the alternate naming convention, both "unary_callable_view" and "nullary_callable_view")?
I think we need only one. You can use bind anyway, to ignore the unneeded arguments. What I am thinking of though, are stateful functions (ala fold). Perhaps it's a good idea to have an initial state that is then subsequently passed to the function at each iteration. Similar to (fold/accumulate): http://tinyurl.com/5hv7bb This can be quite powerful. It means though that the iterator cannot be random-access. Man! The fold algorithm can even be implemented in terms of this view. The only difference is that each "fold" is computed along the way. Maybe we should just call it "fold_view" ?
I started the docs at: http://www.dancinghacker.com/code/dataflow/dataflow/utility/lazy_sequence.ht...
That's a good start. What's still not clear though is the requirements for the function. The fold docs, I think, is a good model for this kind of thing.
I will tease out the docs,tests,naming,directory location,etc. within the dataflow library sandbox until we have something that seems good.
Cool! Thanks! Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net