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;
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk