transparent lambda

Mark Mahieu markmahieu at
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> 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; }

	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.


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

More information about the closures-dev mailing list