Boxing function types

[Doug Lea]

Neal Gafter wrote:
> 
> I'd love to hear you expand on this.  I can't imagine what you might 
> want to change in the core language's exception checking rules.  I've 
> done some language design to support asynchrony, and it transposes to 
> Java very nicely assuming you have support for disjunctive types 
> (exception transparency).
> 

Suppose you'd like to parallelize some function f(x)
by dividing it into left and right parts.
Using you-know-what-I-mean syntax:
   invokeAll(new F(left(x)), new F(right(x)));
by which you have implicitly claimed that the left
and right computations commute (i.e., order of evaluation
doesn't matter, so can run in parallel). But suppose
you are wrong about this claim in that:
when run sequentially, the left side
throws an exception before proceeding to right.
Now suppose that the right side also throws an exception.
And finally suppose that when run in parallel, the right
side throws an exception before the left even starts.
We want to (and do in FJ) just throw that right-side
exception, and make no claims in this case about
the left side, since we really don't know what would have
happened if run sequentially; and further are free not
to run it at all or kill it if the right side throws.

So the issue is: If a programmer (perhaps implicitly)
claims that two computations commute, then
the exception thrown should be able to reflect
that assumption, so (re)throwing any exception encountered
should be OK. (Some people take the alternative
view that you should throw a bundled Exception
that represents all encountered exceptions, but
doing so is hard to mesh with common
policies to cancel sibling tasks upon first exception.)

-Doug