Return Isn't Transparent

[Howard Lovatt]

@Neal,

> Control-flow and reachability analysis is completely transparent in BGGA.

That doesn't really answer the question directly.

What about a minor variation in BGGA'ish syntax:

 int m() {
   final { -> Nothing } return42 =  { -> return 42; }.();
   return42.();
   // Oops error - must return value from m
 }


  -- Howard.

On 18 July 2010 11:38, Howard Lovatt <howard.lovatt at gmail.com> wrote:
> Hi Neal,
>
> Are you saying that there are *no* cases where BGGA cannot reason
> about the control flow? This is a slightly different question than
> saying that a new language could not be designed with transparency in
> mind.
>
>   -- Howard.
>
> On 18 July 2010 01:15, Neal Gafter <neal at gafter.com> wrote:
>> On Sat, Jul 17, 2010 at 6:46 AM, Howard Lovatt <howard.lovatt at gmail.com>
>> wrote:
>>>
>>> A return statement isn't transparent. This is well articulated in
>>> Principles of Programming Languages R. D. Tennent (I don't have a copy
>>> handy - but I think page 56 is one such place). Consider:
>>>
>>> int m() {
>>>  return 42; // To be wrapped in a lambda
>>> }
>>>
>>> Then imagine that you could create a lambda that encapsulated the long
>>> return and you called it:
>>>
>>> int m() {
>>>  { -> return 42; }.();
>>>  // Oops error - must return value from m
>>> }
>>
>> This works just fine in BGGA.  The language can indeed be designed so that
>> return is transparent.
>