Re: [boost] Re: FC++ Formal review is now in progress (2/13-2/23)

From: Brian McNamara (lorgon_at_[hidden])
Date: 2004-02-18 21:36:55

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_at_[hidden])