Boxing function types

[Neal Gafter]

On Mon, Nov 30, 2009 at 5:29 AM, Doug Lea <dl at cs.oswego.edu> wrote:

> 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-

That sounds great, but it also sounds like an API implementation issue, not
a language issue, since it is up to the API to decide what order (or
concurrently) to execute the two functions that are passed in (and what to
do with any exceptions that may arise).  Specifically, in the original code,
the "new F..." creates a function object.  That creation probably throws no
exceptions.  It is only the later invocation of the function that may throw
an exception.  Since there is no invocation of the function appearing in
this source code, the Java Language Specification doesn't say anything at
all about the order in which those exceptions may occur.  So there is
nothing in the JLS to relax regarding these circumstances.

In other words, I don't see any issue with that the JLS currently says and
what FJ currently does.

The only thing I can imagine changing in the JLS regarding this situation is
the addition of disjunction types (exception trandparency), so that it is
possible to correctly type the functions so that checked exceptions can flow
through these APIs.  In other words (using the syntax of 0.6 and greatly
simplifying the fork-join APIs), instead of declaring invokeAll like so:

*void invokeAll(#void() left, #void() right) { ... }*

which doesn't allow the functions to throw any checked exceptions, you
declare it like so:

*<throws X> void invokeAll(#void()throws X left, #void()throws X right)
throws X { ... }*

(the implementation is probably the same) which allows the functions to
throw any checked exception types, and causes the compiler to infer that any
checked exception type that can be thrown by either function will be thrown
by the invocation of invokeAll.

I know the fork-join framework does not currently allow these workers to
throw checked exceptions (because of limited expressivity of Java without
something like the exception transparency of BGGA).  But I don't think there
is any issue about the *order* in which they're thrown.

Cheers,
Neal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091130/b71e1a66/attachment.html