transparent lambda

[Mark Mahieu]

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