transparent lambda
Mark Mahieu
markmahieu at googlemail.com
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'.
Regards,
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091229/ef980c24/attachment.html
More information about the closures-dev
mailing list