Alternative syntax for closures

[Rémi Forax]

Neal Gafter a écrit :
> On Wed, Jul 16, 2008 at 3:24 PM, Rémi Forax <forax at univ-mlv.fr 
> <mailto:forax at univ-mlv.fr>> wrote:
>
>
>            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.
>
>     I don't agree, orphean blocks are rare.
>     so I think it will not catch "the programmer's intent" but most of
>     programmers intent.
>
>
> 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.
>  
>
>
>         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.
>
>     yes
>
>         Second, any attempt to pass a closure containing nonlocal
>         transfers would fail because this method only accepts
>         restricted closures.
>
>     "this method" => which method ??
>     Please note that i don't  call submit() directly.
>
>
> The method named "fork".
Ok,  I understand now, i have used => instead of ==>,
as i said in my blog i'm not able to remember
which arrow defines an unrestricted function type.
So here is the example with the correct BGGA syntax:

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

And you ask me to translate this code using my syntax:
<throws E> void myIf(
     boolean cond,
     {=>void throws E} truePart,
     {=>void throws E} falsePart) throws E {
 (cond ? truePart : falsePart).invoke();
}
There is no way to do that using the syntax
i had proposed.

This code:
void myIf(boolean cond) truePart() falsePart() {
 if (cond)
  truePart().invoke();
 else
  falsePart().invoke();
}
is equivalent to this one:
<throws E> void myIf(
     boolean cond,
     {==>void throws E} truePart,
     {==>void throws E} falsePart) throws E {
 (cond ? truePart : falsePart).invoke();
}

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.

Rémi