Re: [boost] [fusion] adding infinite sequences to fusion

Subject: Re: [boost] [fusion] adding infinite sequences to fusion
From: Stjepan Rajko (stjepan.rajko_at_[hidden])
Date: 2009-05-09 21:17:17

No response to previous mail, so trying again :-)  The overview of the
situation is:

* Fusion currently does not support infinite sequences
* Having infinite sequences would be useful
* We are discussing how to revamp Fusion concepts to allow for
infinite sequences.

Take for a motivating example an undocumented fusion view called
repetitive_view, which results in an infinite repetition of an
underlying sequence.  Here is how it can be used to easily construct
all elements of a sequence with the same argument:

using namespace boost::fusion;

// a Sequence containg 1
vector<int> one(1);
// a quasi-Sequence containing infinitely many ones
repetitive_view<vector<int> > all_ones(one);

// now if we want to initialize any Sequence using all 1s:
vector<int, float, double> s(all_ones);

// and it works
BOOST_CHECK_EQUAL(at_c<0>(s), 1);
BOOST_CHECK_EQUAL(at_c<1>(s), 1.0f);
BOOST_CHECK_EQUAL(at_c<2>(s), 1.0);

I have encountered scenarios where I needed to construct each element
of a Sequence using the same argument, and the above method is much
nicer than anything else I tried.  The problem is that repetitive_view
doesn't result in a valid Sequence per current Fusion concepts (that
is why it isn't documented).

In an effort to fix the problem, there's been some off-list discussion
between Dan Marsden, Joel de Guzman and myself on how to address
infinite sequences in Fusion concepts. Joel suggested to bring the
discussion back to the list for more feedback.  Below is the latest
proposal for revamped Fusion concepts, and some responses by Joel and
myself.

If anyone is at all interested in infinite fusion sequences, please comment.

On Sat, Apr 18, 2009 at 4:53 PM, Stjepan Rajko <stjepan.rajko_at_[hidden]> wrote:
>
> On Wed, Apr 15, 2009 at 6:21 PM, Joel de Guzman <djowel_at_[hidden]> wrote:
>> Stjepan Rajko wrote:
>>>
>>> Here is a list and description of all of the concepts that might be
>>> relevant:
>>>
>>>
>>> Forward Sequence
>>> begin(s) - returns a Forward Iterator
>>> empty(s) - returns a bool
>>> front(s) - any type
>>>
>>> Finite Forward Sequence
>>> refines Forward Sequence
>>> end(s) - returns a Forward Iterator
>>> size(s) - MPL integral constant
>>>
>>> Infinite Forward Sequence
>>> refines Forward Sequence
>>> empty(s) - returns false
>>> size(s) - infinity
>>>
>>> Bidirectional Sequence
>>> refines Forward Sequence
>>> begin(s) - returns a Bidirectional Iterator
>>>
>>> Finite Bidirectional Sequence
>>> refines Bidirectional Sequence, Finite Forward Sequence
>>> end(s) - returns a Bidirectional Iterator
>>> back(s) - any type
>>>
>>> Infinite Bidirectional Sequence
>>> refines Bidirectional Sequence, Infinite Forward Sequence
>>>
>>> Random Access Sequence
>>> refines Bidirectional Sequence
>>> begin(s) - returns a Random Access Iterator
>>>
>>> Finite Random Access Sequence
>>> refines Random Access Sequence, Finite Bidirectional Sequence
>>> end(s) - returns a Random Access Iterator
>>>
>>> Infinite Random Access Sequence
>>> refines Random Access Sequence, Infinite Bidirectional Sequence
>>>
>>>
>>> How does that look?
>>
>> I'd suggest posting that to the Boost list to get more feedback.
>> I have a feeling that infinity is a separate concept orthogonal
>> to traversal. But I'm not sure.
>>
>
> The above layout is almost orthogonal, with Infinite Forward Sequence
> and Finite Forward Sequence serving as "base" concepts related to
> Finite / Infinite.  I suppose you could have less refined Infinite
> Sequence and Finite Sequence concepts, but I'm not sure how useful
> they would be (AFAICT, they could only describe `size` and `empty`).
>
> Things aren't perfectly orthogonal because Finite + Bidirectional
> require `back`, but Finite + Forward do not, and neither do Infinite +
> Bidirectional.
>
> Best,
>
> Stjepan
>
>
>> Regards,
>> --
>> Joel de Guzman
>> http://www.boostpro.com
>> http://spirit.sf.net
>>
>