Alternative syntax for closures

[Neal Gafter]

On Wed, Jul 16, 2008 at 4:44 PM, Rémi Forax <forax at univ-mlv.fr> 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"); })
  .Dispatch("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
http://gafter.blogspot.com/2006/10/concurrent-loops-using-java-closures.html.
 I expect to provide an implementation of the eachConcurrently API
with
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...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20080716/89f061a3/attachment.html