transparent lambda

Mark Mahieu markmahieu at
Tue Dec 29 11:50:39 PST 2009

On 29 Dec 2009, at 16:53, Neal Gafter wrote:
> I therefore think the variation in which the label is mandatory is more promising.  It also has the advantage that we can use a context-sensitive keyword for "yield".

That's something I'm definitely in favour of, if it turns out to be workable; at the risk of sounding like a broken record, yielding from a lambda and returning from the enclosing method are related but distinct mechanisms which are easily confused, and I believe that mirroring the distinction with an obvious difference in surface syntax would help greatly in avoiding that confusion.

>   However, I don't think you've perfected it yet.  Two issues come to mind:
> I'm afraid there might be some ambiguity with function types.  Specifically, is "#X() Y" the declaration of a variable Y of function type "#X()", or is it a lambda labelled X whose value is Y?  Adding mandatory parens around the expression part of a lambda expression might help.

The JLS already declares that statements may be prefixed by a label, so isn't there already a natural position for the label to occur in a StatementLambda?

	#() label: { /* block */ }

That doesn't seem too bad to me.

> I think the labelled yield syntax could be improved.  I suspect something like "yield label : expression;" would be easier on the eyes.
Yes that looks ok.  There might be a slight readability issue when the expression contains a conditional ?: operator, but that's probably no big deal.

Presumably you'd also want to support using this in lambdas with a void result type, which might then be as simple as:

	yield label;

With a new 'yield' keyword, I think that gives us a nice (syntactic) relationship with the use of labels and break/continue.  It's notable that it would not work out so well with 'return'.


-------------- next part --------------
An HTML attachment was scrubbed...

More information about the closures-dev mailing list