Re: [boost] AlRangeExandrescu?

Subject: Re: [boost] AlRangeExandrescu?
From: David Abrahams (dave_at_[hidden])
Date: 2009-07-23 09:26:14

on Thu Jul 23 2009, Neil Groves <neil-AT-grovescomputing.com> wrote:

> 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.

At the moment, I'm not really concerned with the specific syntax choice
so much as the whole idea that the system composes much better with a
ranges-in/ranges-out interface.

> 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(). 

?  Sorry, I don't see how that is any different from having an iterator
range whose begin iterator can be dereferenced, as the current STL
algorithms do.  Anyway, front() and back() can always be interchanged by
reverse().

I encourage you to consider his work a bit more than briefly.

> 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.

I don't think it needs fixing, but maybe I'm missing something.

> Wouldn't a change of this magnitude require a fresh review? 

No; once a library passes review, the maintainer can make arbitrary
changes.  It's important to be conscientious about that, of course.

> 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. 

IIRC he did his work in D, and that his library doesn't exactly have all
the features we may want from RangeEx.  But it would be a very good idea
to discuss what he learned with him and attempt to benefit from it.

> 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.

I don't think any "heavy weight names" have the time to take this over.
You got this library accepted; it's your baby.  Please don't be
intimidated just because I'm suggesting you look at some new ideas.

>> 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. 

It counts for something, but generic programming starts by collecting
and surveying *all* the algorithms in a domain and then clustering the
requirements of those algorithms into concepts.  I'm not sure if your
applications demand enough use cases to really prove the Range concept,
so to speak.  Since the STL started with a complete survey (of a certain
class of algorithms), concepts that can be used to implement its
algorithms have extra credibility.

> Probably other people using the code would be far more valuable.

Always.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com