Re: defer call

From: jaakko.jarvi_at_[hidden]
Date: 2001-06-14 02:43:17

> The problem is that a bind library tends to grow uncontrollably and
since
> the 'Bind' part of Lambda is scheduled right after the 'Tuple'
part... you
> get the idea. :-)
> 
> Identifying a 'simple' bind subset isn't easy, since different
people have
> different needs.

I agree with the uncontrollable growth. A code that performs the
placeholder substitutions with function composition is already over
'simple'. And once that part is done, why not add binding of
operators, and why not control structures ...

We're cutting LL into smaller pieces. tuples became a separate library 
as it is really quite different concept of binding. It is just a tool
that LL uses.
bind wont't become another library, but rather the 
user include features like bind functions, operators, control 
structures separately, and each of these include the core machinery
to make argument substitution and return type deduction work.

Anyway, I like the idea of making LL and function work together.
But if we take that step, why confine it to just bind invocations:

If something like this would work:

ostream& print(ostream& o, int i) { return o << i; }
function<ostream&, int> outputter = bind(print, ref(cout), free1)
// ref is to make bind store cout as reference
outputter(1);

why not:

function<ostream&, int> outputter = (cout << free1)
outputter(1);

One detail that requires thinking is that LL stores some of the bound
arguments as references.
E.g. the function object resulting from a lambda expression 
a += free1 holds a reference to a. 
In current LL this is ok, as the function objects cannot really be
stored for future use, but are constructed and evaluated at the same 
site.
Now, if we store the function object into a variable, 
there's a fear for dangling references.

int *a = new int();
function<int&, int> f = (*a += free1);
f(7); // ok
delete a;
f(7); // dangling reference

Cheers, Jaakko