Re: [boost] AlRangeExandrescu?

Subject: Re: [boost] AlRangeExandrescu?
From: Neil Groves (neil_at_[hidden])
Date: 2009-07-23 09:07:30

Hi Dave,

On Thu, Jul 23, 2009 at 1:48 PM, David Abrahams <dave_at_[hidden]> wrote:

> Hi Neil,
>
> I'm sure someone already spoke to you about this, but just in case: Andrei
> Alexandrescu gave a very interesting presentation at BoostCon that was based
> on a "ranges only" approach that should eliminate issues like this one:
>
>  2: return type specification for find() etc
>  ===========================================
>  There where no major objection to the mechanism, but some found
>  the syntax ugly. I believe the suggested syntax (e.g.)
>
>   boost::find[_f,_e]( range, x )
>
>   boost::find[_f+1,_e]( range, x )
>

The current syntax that was proposed is not like this. In fact one need do
no more than boost::find(range, x) for the default behaviour, but for
obtaining a non-default range then something like
boost::find<find_end>(range, x) is used. I don't find this very ugly and if
one is going to allow a selection of differing return types then the choice
needs to be made via a parameter somewhere whether one supports different
Range concepts or not.

I have briefly considered Alexandrescu's proposal, I am very excited to see
a concrete proposal to make Range Concepts first class citizens, but on
first glance they appear to introduce a coupling between traversal and
access.Having a front() accessor member function as part of a Range Concept
means that generic algorithms that are passed a range would need to know
they were extracting from the front() or the back(). I haven't had time to
think this through completely but it isn't clear to me at least that
everything that is currently possible can be done with the suggested
concepts. I'm also not sure how to fix the (imagined?) issue.

Wouldn't a change of this magnitude require a fresh review? I'm not against
doing this. In fact, if Andrei has already an implementation it may be best
all around if his version is proposed instead. The current RangeEx is far
more modest in it's aims, and perhaps this is simply not going far enough in
the light of recent advances. I'd be happy to work with anyone that is
interested in thrashing out superior Range Concepts. Also I think it only
sensible to offer stepping down in the light of the very heavy weight names
that now may be interested in taking this over if this would speed the
progress along. I would very much prefer to continue and assist if at all
possible without hindering things.

>
>
> He says he's implemented a superset of the STL algorithms with it so we
> know the expressive power is fairly complete.  I was wondering if you had
> given any thought to making use of his insights?  Especially considering
> that RangeEx hasn't been used to fully cover a generic domain (I think), it
> might make sense.
>

I have used Boost.RangeEx not just to implement algorithms, but also to
implement applications using the algorithms. I'm not really sure this counts
for much however. Probably other people using the code would be far more
valuable.

>
> --
> David Abrahams
> BoostPro Computing
> http://boostpro.com
>

 Regards,
Neil Groves