Alternative syntax for closures

[Neal Gafter]

On Wed, Jul 16, 2008 at 6:39 AM, Rémi Forax <forax at univ-mlv.fr> wrote:

>
> Your syntax is ambiguous.  There is no way to tell if it is to be parsed as
>> a single invocation
>>
>>   IDENTIFIER ( ARGS ) BLOCK BLOCK
>>
>> or an invocation followed by a block
>>
>>   IDENTIFIER ( ARGS ) BLOCK
>>   BLOCK
>>
> yes, the syntax is ambiguous but it can be solved by prefering the former
> than the later.


I don't think there is any reason to believe that the former is more likely
to be the programmer's intent than the latter.


>
>
>>
>>        How do I get exception transparency for non-trailing arguments?
>>
>>    There is no way.
>>
>>
>> Then I presume there is also no way to declare local variables or fields
>> to store closures that have parametric exceptions, which rules out a number
>> of useful control APIs.  Your proposal is not just a different syntax for
>> the same semantics; it supports only a subset of the useful functionality of
>> BGGA.
>>
> Not exactly.
> Closure block types are used internally by the compiler but can't be
> declared by a user.
> If you want to store such closure in a local variable or a field, you have
> to convert it
> to a function type.
>
> The idea behind is that if you store a closure block in a field (or a
> final/shared local field)
> you have lot of chance to get an exception at runtime.
>
> By example, this code (BGGA syntax) may work or not
> depending if you have return/break/continue
> in the closure block.
>
> Executor executor=...
> ...
> <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
>   }
>  });
> }


This example would fail at compile-time in BGGA for at least two reasons:
first, the exception E is thrown in run() but not declared.  Second, any
attempt to pass a closure containing nonlocal transfers would fail because
this method only accepts restricted closures. So I don't see what "problem"
with this example you're solving.


> The same example with my syntax
>
> void fork() block() {
>  final void() throws Exception b =
>  (void() throws Exception)block; // cast is needed here
>  executor.submit(new Runnable() {
>   public void run() {
>      b.invoke(); // try/catch Exception needed here
>   }
>  });
> }


If the cast succeeds (i.e. there is a subtype relationship), requiring a
cast doesn't really make sense from a typing perspective.

I don't see a difference with BGGA's functionality.


It looks like your proposal allows exactly the kind of code you're concerned
about, while BGGA forbids it.  Your framework doesn't appear to support
general exception transparency, as there is no way to store closures that
are parameterized by the types of the exceptions they can throw.  You've
mentioned at the existence of these "closure" types, but I don't know what
types rules you have in mind for them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20080716/c53b6dd8/attachment.html