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. Dealing with references is relatively straightforward for first-order functoids, but when you deal with higher-order ones, it quickly becomes hard (impossible?) to do the right thing. For example: suppose we want to write a functoid "app", such that app( f, x ) == f(x) Should the second parameter be "by value" or "by reference"? The "right answer", IMO, is that it depends on whether "f" takes its argument by value or reference. Except that this dependency now excludes many uses of app(), such as app( _, 3 ) Even though the result of that may be later used in a context that should/would be legal, "right now" we don't know if we should be copying the 3 or trying to take a reference to it. Whichever choice we make, it might turn out to be the "wrong" choice later. boost::lambda's "solution" is to always take reference parameters; this is why we have (_1 + _2)( 5, 7 ) // no, not 12--it's illegal 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. I need to advertise this as the main reason we don't do references in FC++; it's kinda a tough argument to follow, but once you understand it, you see that there's no way to make things work "right". -- -Brian McNamara (lorgon@cc.gatech.edu)