Alternative syntax for closures

[Rémi Forax]

Neal Gafter a écrit :
> On Tue, Jul 8, 2008 at 12:42 AM, Rémi Forax <forax at univ-mlv.fr 
> <mailto:forax at univ-mlv.fr>> wrote:
>
>     Furthermore, i don't like exception type parameter, too complex
>     too, that why i've proposed
>     a different syntax for method that takes an unrestricted closure,
>     this allow to
>     perform exception transparency seamlessly and avoid create a type
>     for unrestricted function type
>     (like T... which is only available in method declaration).
>
>
> I'd love to see the semantic rules that you have in mind to achieve 
> exception transparency.
>
I just come back from vacation, sorry for the delay.
Better with an example:

static void with(Closeable closeable) block() throws IOException{
  try {
    block.invoke();
  } finally {
     closeable.close(); // may throw an IOException
  }
}

...
FileReader reader=...
with(reader) {
  throw new AnotherException();
}

is compile like this:

interface VVE {
  void invoke() throws Exception;
}

static void with(Closeable closeable, VV block) throws Exception {
  try {
    block.invoke();
  } finally {
     closeable.close(); // may throw an IOException
  }
}

...
FileReader reader=...
with(reader,new VVE() {
   public void invoke() throws AnotherException {
     throw new AnotherException();
   }
});

here the compiler awaits two catch blocks
to catch AnotherException and IOException.

As i said, i've just proposed a new syntax, not a new semantics.
Rémi