Re: [boost] [mpl]iter_fold_if Forward Backward rationale?

Subject: Re: [boost] [mpl]iter_fold_if Forward Backward rationale?
From: Larry Evans (cppljevans_at_[hidden])
Date: 2009-05-19 14:11:50

On 05/18/09 17:19, Steven Watanabe wrote:
> AMDG
> 
> David Abrahams wrote:
>> on Sun Apr 05 2009, Larry Evans <cppljevans-AT-suddenlink.net> wrote:
>>  
>>> Just as the ForwardPredicate is "augmented" with protection
>>> against dereferencing the end<numbers>::type in this code:
>>>
>>> https://svn.boost.org/trac/boost/browser/trunk/boost/mpl/iter_fold_if.hpp#L42 
>>>
>>>
>>> shouldn't the BackwardPredicate also be augmented with the same
>>> protection here:
>>>
>>> https://svn.boost.org/trac/boost/browser/trunk/boost/mpl/iter_fold_if.hpp#L77 
>>>
>>>     
>>
>> Well, it doesn't need to be; if it did, tests and uses wouldn't compile
>> ;-)
>>   
> 
> Alas.  AFAICT, there are no tests or uses for the Backward Predicate in 
> MPL.
> 

However, there may be a use in the future.  For example,
reverse_find_if.  Of course one could implement that by first doing a 
reverse and then a find_if, but then using that rationale, one could 
argue there's no need for reverse_fold.

I've actually got a use case:  error recovery in LL1 parsers.
I can't remember the details, but just as find_if could be
used to find the first non-nilable element in a spirit sequence,
one could use a reverse_find_if to find the last non-nilable
element in the same sequence.  From the Lewi reference in
the vault's

   Home /Strings Text Processing/LewiLL1.lhs_rhs.zip

there's some method of using this to calculate error
recovery.  IIRC, it's calculated just like the First
attribute shown in the vault reference, except the
sequence is reversed.  There would be no need to reverse
the sequence if reverse_find_if were available, and
reverse_find_if can be implemented using the
BackwardPredicate withe ForwardPredicate being always<true_>.