"Brian McNamara" <lorgon@cc.gatech.edu> escribió en el mensaje news:20040219023655.GA20333@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