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-06-04 11:43:46

On 05/29/09 16:02, Steven Watanabe wrote:
]snip]

 > The only case where it is significantly more convenient to use the
 > backward predicate is when doing both a forward and a reverse
 > operation.  For this case, what is really needed is the ability to
 > give iter_fold_if a lambda expression which will be used to package
 > the result of the forward operation for the backwards operation.
 > (This is all premature generalization of course...)

IIUC, this "lambda expression..for the backwards operation" would be
used to test if the BackwardPred were satisifed, and only then would
the oringinal backwards operation be applied; otherwise, the backward
operation would just be the identity operation.  If so, then that's
what I was suggesting here:

   AFAICT, the only purpose of BackwardPredicate is to prevent selected
   BackwardOp applications "on the way out" (to quote from

     http://article.gmane.org/gmane.comp.lib.boost.devel/188246

   ). However, that role could be performed by the BackwardOp itself,
   couldn't it?

from:

   http://article.gmane.org/gmane.comp.lib.boost.devel/188358

Now AFAICT, the if_recur template, mentioned in the previous sentence
to that suggestion, is functionally equivalent to the your proposed
modification to iter_fold_if_impl because it doesn't have the
BackwardPred either.  The difference is that if_recur doesn't have the
2 calls to BOOST_PP_REPEAT whose only purpose, AFAICT, is to alleviate
the "template instantiation depth" limitation described here:

   http://www.mywikinet.com/mpl/paper/mpl_paper.html#sequences.unrolling

The advantage of if_recur is that it's clearer because:

   1) if_recur doesn't try to alleviate the template instantiation
      depth problem and therefore doesn't use any BOOST_PP_REPEAT
      calls.  Such BOOST_PP_REPEAT calls obscure the code.

      Maybe there's some if_unrolled_recur, based somehow on if_recur,
      that could alleviate the template instantiation depth problem
      using BOOST_PP_REPEAT. However even if if_unrolled_recur is used,
      the if_recur code should be kept around for documentation.  IOW,
      just as the mpl_paper.html document showed fold_impl before and
      after the unrolling, the rationale or implementation doc for
      if_unrolled_recur would show the original (and clearer) if_recur
      and explain how if_unrolled_recur was derived from if_recur based
      on the pattern in the mpl_paper (or some other document within
      mpl docs or boost docs).

   2) The other reason if_recur is clearer is that it generalizes the
      fold problem into a recursive if-else problem.  The recursive
      if-else is clearer because everyone is familiar with both the
      if-else construct and recursion and the if_recur just has fewer
      template parameters than iter_fold_if_impl and this makes it
      easier to understand.  Of course those if_recur template
      parameters have to be constructed from the ForwardPred and
      ForwardOp and BacwardOp args to iter_fold_if, but that has to be
      done with the existing code.

      In this case, the generalization is a help w.r.t. code clarity;
      hence, I don't think it should be characterized as premature
      generalization.

Actually, the only reason for the while_ template mentioned here:

   http://article.gmane.org/gmane.comp.lib.boost.devel/188775

is to allow the short-circuiting going up the recursion stack, an
advantage not possible with if_recur.  I thought that would be more
acceptable than if_recur because it seemed important in this post:

   http://article.gmane.org/gmane.comp.lib.boost.devel/171634

If short-circuiting is considered an advantage, then why not use the
while_?

[snip]