related link

[John Nilsson]

On Tue, Feb 9, 2010 at 12:34 AM, Neal Gafter <neal at gafter.com> wrote:

> On Mon, Feb 8, 2010 at 2:45 PM, John Nilsson <john at milsson.nu> wrote:
> > On Mon, Feb 8, 2010 at 8:03 PM, Neal Gafter <neal at gafter.com> wrote:
> > A quick and dirty pretend syntax (didn't really spend too much time
> thinking
> > about concurrency, but I'm assuming that any issues can be address within
> > the macro construct).
>
> The problem isn't syntax, it's semantics.  I don't see how your API
> makes return/break/continue "do the right thing" from the API client's
> point of view.  You seem to treat break and return identically, for
> example, but they don't have the same meaning at all.
>

The idea behind the try syntax thing was that the macro would inject the
code blocks at the points where the client used break/continue/return but
keep the actual control transfer (in relation to the defined block).  A
slight modification to standard Java might be required to allow breaks and
continues from any block.

Both break and continue jumps to the end of the block and triggers the
behaviour specified by the macro. return returns from the method where the
block was declared but triggers the trapped behaviour.

Using the try-syntax I was trying to appeal to the known semantics of
finally-clauses.

BR,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20100209/159942e1/attachment.html