<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Neal Gafter wrote:
<blockquote
 cite="mid:15e8b9d20912142244k79b42ebeua6c72be06f475a27@mail.gmail.com"
 type="cite">
  <div class="gmail_quote">On Mon, Dec 14, 2009 at 9:52 PM, Jonathan
Gibbons <span dir="ltr">&lt;<a moz-do-not-send="true"
 href="mailto:Jonathan.Gibbons@sun.com">Jonathan.Gibbons@sun.com</a>&gt;</span>
wrote:<br>
  <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
    <div bgcolor="#ffffff" text="#000000">
    <div>There is still potential confusion for the programmer using
lambda
expressions however.<br>
    </div>
    <br>
Someone reading 0.6a might reasonably infer that an expression lambda
could easily be converted to statement lambda by adding a "return" and
changes parens to curlies.</div>
  </blockquote>
  <div><br>
I think that issue is mainly academic.&nbsp; I'd be surprised to find
someone trying to use an expression lambda with a block expression
(i.e. statements in the parens).&nbsp; Given the existence of statement
lambdas, the code would be awkward for no apparent reason.&nbsp; The only
real reason to do so would be to be able to use the nonlocal transfers
in a context where you can't use the control invocation syntax (e.g.
there are two controlled blocks to pass to a method).&nbsp; If you try to
change a lambda from expression lambda to statement lambda, the
transfers become compilation errors (except for a return statement in
the unlikely event that the enclosing method and the lambda have the
same return type).<br>
  <br>
Most people nowadays make such local transformations using IDEs, and
the IDE would presumably know how to do it correctly.<br>
  <br>
  </div>
  <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
    <div bgcolor="#ffffff" text="#000000">If 0.6a were all there was,
that would
work.&nbsp;&nbsp; But in 0.6b, you've added block expressions. They look great -
I want to use them - but they've broken that "obvious" rule relating
expression lambdas to statement lambdas. Suddenly, there is a
substantial non-obvious difference between expression lambdas and
statement lambdas.<br>
    </div>
  </blockquote>
  <div><br>
I think it's pretty obvious that "return" means something different.&nbsp;
That's the whole point of introducing statement lambdas.&nbsp; break and
continue just turn into compile-time errors.<br>
  </div>
  <div><br>
  </div>
  <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
    <div bgcolor="#ffffff" text="#000000">With the for loop invocation
syntax, we get to add another modifier to
the signature, which makes it very clear this is a different sort of
function type.</div>
  </blockquote>
  <div><br>
The for modifier doesn't affect the function type, but I see where
you're going with this.<br>
&nbsp;</div>
  <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
    <div bgcolor="#ffffff" text="#000000">Is there any similar way we
could mark the type of any
function type that is to be used for control flow abstraction, not just
for loops? This would then avoid the need for the subtle semantic
difference between expression lambdas and statement lambdas, and avoid
the downstream puzzlers comparing the behavior of the two.<br>
    </div>
  </blockquote>
  <div><br>
Puzzlers are only worrisome if they bite you, and I believe this one
doesn't.<br>
  <br>
The "for" modifier on the method doesn't affect the interpretation of
the lambda or its contents... it is the appearance of the "for" on the
invocation that changes the labels that are in scope when the lambda
occurs.&nbsp; I would be very concerned about having the target type affect
the meaning of the lambda body.<br>
  <br>
I believe you still need both kinds of lambdas: you need expression
lambdas for things like concise aggregate operations, and some people
have insisted that you need statement lambdas where returning early is
important for structuring the computation.&nbsp; So you're probably talking
about a third lambda form.&nbsp; It is the lambda that needs another form,
not the function type, even if you are saying that you like the
restricted versus unrestricted
function type distinction from BGGA, and want to
bring that back into this revision of the spec.<br>
  <br>
  </div>
  <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
    <div bgcolor="#ffffff" text="#000000">P.S. It wouldn't be quite so
bad if the difference were the other way
around, with local return, no break/continue in expression lambdas, and
non-local return in statement lambdas, but it would still be even
better if we could make the difference more explicit, somehow.<br>
    </div>
  </blockquote>
  <div><br>
I think the current spec is a worthwhile simplification versus BGGA,
but I'd be happy to entertain further revisions.&nbsp; Maybe you like BGGA's
lambda syntax for these "blocks" ?<br>
  <br>
Cheers,<br>
Neal<br>
  <br>
  </div>
  </div>
</blockquote>
<br>
<br>
I don't think you need any new syntax for the invocation. If it looks
like a lambda expression (as in Mark's proposal, or your 0.6a), it is a
"standard" lambda expression, with local control flow (return is local,
no break/continue).&nbsp;&nbsp; If it looks like control invocation syntax, it is
an "extended" lambda expression, with non-local control flow (return is
non-local, break/continue allowed depending on context.)&nbsp; The only
thing I would suggest is a more explicit marker on the parameter type
to indicate that an extended lambda expression is expected.<br>
<br>
-- Jon<br>
</body>
</html>