Alternative syntax for closures

[Rémi Forax]

Neal Gafter a écrit :
> On Wed, Jul 16, 2008 at 6:39 AM, Rémi Forax <forax at univ-mlv.fr 
> <mailto: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.
I don't agree, orphean blocks are rare.
so I think it will not catch "the programmer's intent" but most of 
programmers intent.
>  ...
>
>     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.
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.
> 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.
There is a subtyping relation between  function type and closure type
(restricted/unrestricted function type).
>
>     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.
No, BGGA don't forbid it.
> Your framework doesn't appear to support general exception transparency,
yes, it don't because i don't think it's necessary.
> as there is no way to store closures that are parameterized by the 
> types of the exceptions they can throw.
the function type will be not parametrized.
> You've mentioned at the existence of these "closure" types, but I 
> don't know what types rules you have in mind for them.
closure block type => BGGA's unrestricted function type
function type => BGGA's restricted function type

Rémi