Return Isn't Transparent

[Howard Lovatt]

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 );
       }

might be quite a reasonable thing to do because you want to split a
complicated function into stages and compose the stages.

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.

  -- Howard.


On 21 July 2010 13:00, Neal Gafter <neal at gafter.com> wrote:
> One more thing.  This example is indeed "transparent" because it behaves the
> same as the non-lambda version:
>
>        private static int m6() {
>                if ( true ) { return 42; }
>                if ( !true ) { return 41; }
>        }
>
> Cheers,
> Neal
>
> On Tue, Jul 20, 2010 at 5:58 PM, Howard Lovatt <howard.lovatt at gmail.com>
> wrote:
>>
>> @Neal,
>>
>> Building on Reinier suggestion:
>>
>>        private static int m6() {
>>                final { boolean ==> void } return42 = { boolean b ==> if (
>> b ) {
>> return 42; } };
>>                final { boolean ==> void } returnNot41 = { boolean b ==> if
>> ( !b ) {
>> return 41; } };
>>                return42.invoke( true );
>>                returnNot41.invoke( true );
>>        }
>>
>> Presumably for difficult examples like this you would have no
>> expectation of them working, which was my point that in general you
>> can't have return transparency because analyzing the expressions is
>> too difficult for the compiler.
>>
>>  -- Howrad.
>>
>> On 21 July 2010 02:06, Neal Gafter <neal at gafter.com> wrote:
>> > On Tue, Jul 20, 2010 at 8:55 AM, Reinier Zwitserloot
>> > <reinier at zwitserloot.com> wrote:
>> >>
>> >> What happens when the closure isn't ===> Nothing, but ===> Void, e.g.
>> >> to
>> >> fit the parameter type of a bggaBasedForEach() method?
>> >
>> > Invoking something that is declared to return Void is considered by the
>> > compiler to be capable of completing normally.  That's what you want for
>> > a
>> > for-each loop: a loop can complete normally even if its iterations
>> > can't,
>> > because it may execute zero iterations.
>> >
>> > -Neal