Alternative syntax for closures

Neal Gafter neal at
Wed Jul 16 17:16:48 PDT 2008

On Wed, Jul 16, 2008 at 4:44 PM, Rémi Forax <forax at> wrote:

> Neal Gafter a écrit :
>> I fundamentally disagree with designing a language based on an ambiguous
>> syntax.
> expr + expr + expr is ambiguous but it doesn't seem to be a big problem.

Actually, it isn't. The Java grammar supports only a single parse of this.

> <throws E> void fork(
>  final {==>void throws E} block) throws E {
> executor.submit(new Runnable() {
>  public void run() {
>    block.invoke(); // need a try/catch E here
>  }
> });
> }
> Are you agree that this example raise an exception
> is break/continue or return are used in the closure block ?

No; this implementation of "fork" won't even compile (E is thrown but not
caught or declared in run()).

> My point is that only unrestricted closure needs exception transparency,
> that why there is a special syntax for defining method that takes
> an unrestricted closure as parameter.

I disagree.  Exception transparency is also useful outside control APIs, and
even in control APIs there are cases where one needs to store the closure in
a variable.  Doing so in a typesafe manner is better than requiring a cast.
For a simple example, try writing an API that can be used this way:

new StringSwitch()
  .Case("xyzzy", { ==> System.out.println("found xyzzy"); })
  .Case("plugh", { ==> System.out.println("found plugh"); })
  .Case("foo", { ==> System.out.println("found foo"); })

Your implementation should support exception transparency and control
transparency.  I believe you'll find that you need to store closures that
have parametric exception types.

See also
 I expect to provide an implementation of the eachConcurrently API
one of the upcoming BGGA prototypes.  I don't think this is possible with
your formulation.

A number of people who are most concerned about supporting control APIs in
BGGA nevertheless advocate adding support for exception transparency.
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the closures-dev mailing list