From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2004-02-19 12:06:15
"Brian McNamara" <lorgon_at_[hidden]> escribió en el mensaje
news:20040219023655.GA20333_at_lennon.cc.gatech.edu...
> 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
> http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1385.htm
> ). 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(_,3)(f);
app(_,x)(g); // compile-time error, cannot bound a reference to a
temporary.
app(_,ref(x))(g); // ok
Fernando Cacciola
SciSoft