Return Isn't Transparent

[Pavel Minaev]

On Tue, Jul 20, 2010 at 10:01 PM, Howard Lovatt <howard.lovatt at gmail.com> wrote:
> I would argue that if you can't do any re-factoring - what's the
> point? Starting with something along the lines of:
>
>       private static int m6( final boolean b ) {
>               if ( b ) { return 42; }
>               else { return 41; }
>       }
>
> and re-factoring to:
>      private static int m6( final boolean b ) {
>               final { boolean ==> void } return42 = { boolean b ==>
> if ( b ) { return 42; } };
>               final { boolean ==> void } returnNot41 = { boolean b
> ==> if ( !b ) { return 41; } };
>               return42.invoke( b );
>               returnNot41.invoke( b );
>       }

There is no "refactoring" in the definition of transparency.

In any case, your code is still not equivalent according to Java
reachability rules: "if (x) return; if (!x) return;" is not treated
the same as "if (x) return; else return;" outside of lambdas as it is,
so why it should be treated any differently inside them? That's what
transparency is all about - that things just keep working the same
way.

> If the limitation is that you pretty much have to wrap the whole
> expression to get transparency, then the use cases are reduced to
> simple serial execution like the existing loops and if structure. This
> doesn't sound that useful, since these structures already exist.

Only some primitive forms of loops exist in Java on language level.
The whole point of transparency as implemented by e.g. BGGA is to be
able to implement more advanced control structures as libraries -
including, yes, more advanced loop forms (e.g. a loop over several
collections in parallel).