[Review] bind

From: jaakko.jarvi_at_[hidden]
Date: 2001-08-20 03:47:23

Hi Peter and others, 

Sorry for commenting so late in the process, it's already past 19th,
but
as the review period is not officially declared to be over, I hope I'm
still on time.

Like Peter said, bind is kind of a partial solution while waiting for
a 
more full-fledged expression template library.
The LL has been sitting in the vault for quite some time, but it will
be submitted, sooner rather than later, so I want to make sure that
the two libraries
(bind and LL) are not conflicting in their functionalities.

First, bind offers a subset of the functionalities of LL (except for 
the visitor stuff). So in theory, 
if LL is at some point accepted to boost, users could just throw in a
new
include file and things should work. Currently this is not so.
There is a major difference between how arguments are stored within
the 
bound function.
I'm placing a full article about this issue in the Files section 
(directory: lambda, file: about_binding.ps). The paper appeared in the
proceedings of the MPOOL'01 workshop http://www.c3.lanl.gov/~mpool01/

In short, the issue is this:

C++ functions can take their arguments as copies or as references.
In an ideal case, a binding library should just replicate the
prototype of
the underlying function, so that bound arguments that the function 
takes as references should be stored as references, and bound
arguments 
that the function takes as copies, should be stored as copies. 
This is not possible to implement staying inside the 
current language.

The bind library has taken the route to store the bound arguments as
copies, 
except when ref or cref is used, whereas LL tries to make an educated
guess 
whether to store the arguments as references or as copies. 

Here's an example taken from the article:

class turtle { 
...
  void move(const step& s);
};

turtle t;
list<step> s;
...

for_each(s.begin(), s.end(), bind(t, _1)); 
// In LL moves turtle t the steps in the list of steps s
// In Peter's bind library moves a copy of turtle t 

ref(t) can be used (in both libraries) to make bind store arguments by 
reference, the question is just what should be the default.
Please take a look at the article for a more in-depth treatment.

I'm not saying that bind library should be changed to have the same
semantics 
than LL. I'm saying that they should both have the same semantics, 
and LL can be changed just as well. 
I think that this is a deeper issue, and requires careful
consideration and 
it should be discussed before committing us into any one solution.

Other comments
--------------------

I see ref and cref are in the bind library now. What was decided on
this?
Tuples were lifted to boost namespace, and so ref and cref are now in
tuple
and in bind libraries?!
Would 'utility' be a better place for this piece of functionality?

There was a comment on the name bind, and someone considered it bad as
e.g. bind(f, _1, _2) doesn't bind anything. Well, it does, namely the
function f. Anyway, I too chose the name bind in the old binder
library 
(predecessor of LL) for the analogy to  bind1st and bind2nd, 
and I think the name is ok.

_1, _2, ... After seeing these names in Peter's library, we adopted
them
in LL as well. They are short, and kind of nice. They do require you
to 
know the library to understand the code though, but I guess any other
name
doesn't help in this respect either.

The implementation uses a list template of its own, and that's quite a
lot
of code. Would tuples do?

Someone asked this same question: why return_type instead of
result_type?
Isn't result_type the standard name for adaptable functors? In this
way
 the user could write say bind(plus<int>(), _1, _2) instead of
bind<int>(plus<int>(), _1, _2).

Summary
-------
In general, I think bind library is a good temporary solution, I hope
we will 
eventually go to a full expression template library (LL :), 
offering recursive binding, and binding of operator functions as well, 
and free mixing of these.

So I vote for accept, but not until the argument passing/storing
semantics
has been discussed more and a clear stand has been taken.

Cheers, Jaakko