transparent lambda

[Neal Gafter]

[conversation moved from lambda-dev to closures-dev]

On Mon, Dec 28, 2009 at 3:38 AM, Peter Levart <peter.levart at gmail.com>wrote:

>
> Worse, your proposal breaks transparency.  That is explained in detail in <
>> http://gafter.blogspot.com/2006/08/tennents-correspondence-principle-and.html>,
>> ...
>
>
> Being able to return early from a lambda has inherent conflicts with lambda
> transparency since it targets lambda's bounds - lambda becomes visible. In
> spite of that, I think (but I may be persuaded to think otherwise) that it
> is possible to combine transparency to other constructs and "additional
> features" like early return (that break Tennent's principle) in one form,
> provided that those additional features use unique statement forms -
> re-usage of same statements (return, break, continue) among different kinds
> of constructs is not allowed.
>

Yes, it is possible, by using a label.  It is just a bit awkward.  More on
that later.

 That single lambda form is mostly transparent. Non-transparency is obvious
> only when you nest same kind of constructs - features that target those
> kinds then select the innermost one. That's true with loops and methods in
> Java today - they are not transparent to their own kind.
>

The purpose of your proposal was to get transparency.  If you don't mind
being non-transparent, then you need not have proposed anything at all.
Loops are not an abstraction mechanism (more on that later), and methods
don't nest, so the reasons don't apply to them in the same way.

I have read your blog (above link) where you say: "while *existing* code
> doesn't use this new statement form, once we introduce it into the language
> we should expect people to start using it in *new* code. And once they do,
> any code that includes this statement cannot be wrapped in a closure without
> changing its meaning. Once we identified the bad smell this way, it wasn't
> hard to come up with realistic examples where it gets in the way of using
> the language."
>
> What realistic example did you have in mind? Does it get in the way of
> using the language any more than when you try to use nested loops with
> unlabeled break/continue?
>

I don't remember exactly what the examples were, but I hesitate to bring up
particular examples because I'm afraid they'd be used to drive the design
(see <
http://gafter.blogspot.com/2006/09/failure-of-imagination-in-language_17.html>).
The basic property you want of an abstraction mechanism is that the
combination of abstraction (building a lambda) and deabstracting (invoking
it) doesn't change the meaning of what it abstracts.  This is very useful
for refactoring code to remove redundancy.  Any nontransparency interferes
with that kind of refactoring.

Loops are not an abstraction mechanism.  Loops are supposed to change the
execution of the code within them, by repeating their execution.
Nevertheless, there are two syntactic forms of loops: transparent loops and
non-transparent loops, just as we've proposed two forms for lambda
expressions.  The transparent ones are the ones that use a label.  You can
nest these any way you want, and as long as you keep your labels unique and
use labelled break and continue, nesting does not change the meaning of the
statements that are placed within a loop.  Your proposal, while purporting
to introduce transparency, actually remove the transparent (expression
lambda) form by making it non-transparent.

One approach that could be used to have lambdas that are both transparent
and allow early return would be to introduce some kind of labelling
mechanism.  The labelling mechanism could either be part of the lambda
expression syntax or the block expression syntax.  Then, introduce a
labelled return statement, possibly something like this:

*return label : expression;*

I haven't found a way to do this that feels right, but it is an approach
worth exploring.

Cheers,
Neal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091228/8d3deffd/attachment.html