transparent lambda
Mark Mahieu
markmahieu at googlemail.com
Mon Dec 28 12:09:25 PST 2009
On 28 Dec 2009, at 18:18, Neal Gafter wrote:
> On Mon, Dec 28, 2009 at 10:05 AM, Mark Mahieu <markmahieu at googlemail.com> wrote:
> It's a bit of a cheat regarding Tennent's C.P, in that your example could not be refactored to equivalent code simply by wrapping the 'yield' in a (nested) lambda and invoking it - a label would have to be added to make it valid.
>
> That was my point: the existence of an unlabelled yield statement breaks TCP. If the yield statement is labelled, this problem does not occur.
Hmm. Wouldn't it only *break* TCP if it were also valid in a nested lambda but with a different semantic meaning, or if there were no corresponding form for when the statement is wrapped in a lambda?
To put it another way: if we view use of an unlabelled yield statement, such as your example:
#() { yield 3; }
as
a) legal only in a non-nested lambda
b) sugar for the more formal but equivalent labelled form, whereby the yield statement is bound to some compiler-generated label:
someLabel: #() { yield someLabel : 3; }
then the equivalences and correspondences required by TCP appear to me to remain intact. But perhaps I am misinterpreting Tennent's text.
Anyway, I agree that using labels is worth exploring.
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091228/df1b1672/attachment.html
More information about the closures-dev
mailing list