Re: [boost] Formal Review: Boost.RangeEx

Subject: Re: [boost] Formal Review: Boost.RangeEx
From: Neil Groves (neil_at_[hidden])
Date: 2009-02-25 11:00:45

Dear Sir,

On Wed, Feb 25, 2009 at 3:36 PM, Rogier van Dalen <rogiervd_at_[hidden]>wrote:

> On Fri, 2009-02-20 at 13:28 +0100, Thorsten Ottosen wrote:
> > Dear Developers and Users,
> >
> > It's my pleasure to announce that the review of Neil Groves' RangeEx
> > library starts today and lasts until March 3, 2009.
>
> That's great news! I've much anticipated this library, since I'd
> hand-rolled similar components a long time ago. I hope to submit a
> formal review, but before I do, I hope to understand the motivation for
> the design better. I hope this is allowed within a formal review. This
> is related to my question at
> <http://lists.boost.org/Archives/boost/2008/07/140514.php>.
>
> I am not sure I understand the motivation for the operator| syntax. Why
> couldn't
>        vec | boost::adaptors::reversed | boost::adaptors::unique
> be written
>        boost::adaptors::unique (boost::adaptors::reversed (vec))
> ? I think this contrast would be fairer than what the documentation
> currently has. Is there a reason why it is not possible to provide both
> syntaxes? The pipe syntax is nice, but sort of restricts operations to 1
> range in, 1 range out. Relatedly:
>

In the adaptors section the preference for operator| is documented. It
simply chains better in my opinion.

I do provide both alternatives, for example

boost::make_uniqued_range(rng) is equivalent to rng | uniqued

>
> I was hoping for more lazy views on ranges, especially after reading
> that the library allows for a "seamless funtional-style programming".
> Shouldn't there be a generated(), randomly_shuffled(), sorted(),
> intersected(), merged(), etc.? (I implemented lazy set operations
> implemented and I think it's quite possible.)
>

The library is intended to be extended both by myself as core needs become
clear, and by library users. The algorithms, supported range types and
adaptors may be implemented by users of the library without changing it.

Many lazy adaptors are desirable. I would continue to add more as time
permits. My focus is on producing a good foundation for this version. The
reviews are giving me a clearer need of what people want from the library.

>
> In short, I seem to see unexploited symmetries. Am I missing things?
>

There is much unexploited because there is so much one can do. Once this is
out in the wild, I hope to write more, and obtain submissions of adaptors
and algorithms. As the review has continued I wonder if the algorithms
should actually be in Boost.Algorithm and use Boost.Range.

>
> Thanks for any replies,
> Rogier
>

Thank you for your time,

Neil Groves

>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>