Re: [boost] [fusion] constructing all elements of the fusion vector with the same argument

From: Joel de Guzman (joel_at_[hidden])
Date: 2008-07-16 21:48:00

Stjepan Rajko wrote:
> On Tue, Jul 15, 2008 at 7:53 PM, Joel de Guzman
> <joel_at_[hidden]> 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.html

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