Boost logo

Boost :

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2004-02-19 12:06:15

"Brian McNamara" <lorgon_at_[hidden]> escribió en el mensaje
> On Wed, Feb 18, 2004 at 08:04:05PM -0500, Brian McNamara wrote:
> > It occurs to me today that there is some middle ground. Specifically,
> > when you aren't using partial application (that is, "currying" in FC++,
> > or "bind" in boost::lambda), I think that most of the reference issues
> > go away. Perhaps there's a way to implement things so that functoids
> > can have reference parameters, but trying to curry reference parameters
> > is a compile-time error. I'll have to think about that more deeply.
> Oh yeah, the other "hard problem" dealing with reference parameters is
> the "forwarding problem" (as described in
> ). Somehow I always forget about this issue. It's the real killer.
> [A good description of the problems snipped]
> In general, without a context-sensitive type system (like Haskell),
> I think there is no good solution to the problem of multiple parameter
> modes (value and reference) in the context of higher-order functions.
> That is, you cannot write "app" so that both calls here:
> int f(int);
> int g(int&);
> int x;
> ...
> app(_,3)(f);
> app(_,x)(g);
> work properly. It's impossible.

Though the problems you're addressing are real I think the solution is not
to ban reference paramaters altoghether along the entire functoid taxonomy
but to prescribe the following rule:

first-order functoids can take parameters by value or by reference.
high-order functoids should take parameteres only by value (but ref() can be
used by the caller to denote a reference)

Assuming app follows the rule above:

   app(_,x)(g); // compile-time error, cannot bound a reference to a
   app(_,ref(x))(g); // ok

Fernando Cacciola

Boost list run by bdawes at, gregod at, cpdaniel at, john at