<!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:15e8b9d20912151430k78061bb2j1f2726032269ee65@mail.gmail.com"
 type="cite">
  <div class="gmail_quote">On Tue, Dec 15, 2009 at 2:09 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>
    <div class="h5"></div>
    </div>
All fair enough, but wouldn't it be clearer to have some explicit
syntax to indicate transparent rules, rather than (ab)using the
difference between expression lambdas and statement lambdas.&nbsp;&nbsp; <br>
    </div>
  </blockquote>
  <div><br>
I don't think it is abuse.&nbsp; Expression lambdas are always transparent.&nbsp;
Statement lambdas are not.&nbsp; They already have different syntax.<br>
  </div>
  </div>
</blockquote>
<br>
I accept that they have different syntax.&nbsp; They also have different and
obvious meanings depending on whether you want a lambda to be a simple
expression or not.&nbsp;&nbsp; Overloading that relatively simple difference with
transparency semantics is ingeniously clever in a way that is not as
intuitively obvious and clever as the rest of the proposals. My $0.02.<br>
<br>
<blockquote
 cite="mid:15e8b9d20912151430k78061bb2j1f2726032269ee65@mail.gmail.com"
 type="cite">
  <div class="gmail_quote">
  <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">It seems to me that control
flow abstraction is more likely to involve
statement forms, and so anyone wanting to build control flow
abstraction using explicit lambdas is more likely to try and use
statement lambdas,</div>
  </blockquote>
  <div><br>
I think this is confusing the API with the API client.&nbsp; The
abstractions are written as methods and don't involve closures.&nbsp; They
might not even use function types (they could use interfaces instead).&nbsp;
The client, on the other hand, can use whichever form best expresses
the purpose in the client.<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">I guess I'm still trying to
find some suggestions
for explicit syntax to use, that is somewhat more obvious than round vs
curly parens.&nbsp;&nbsp; Maybe some variant of "#" can be used, so that simple #
means simple/standard lambda, and ## or #word or word# (for some word
tbd) could mean a transparent lambda.<br>
    </div>
  </blockquote>
  <div><br>
That was the restricted versus unrestricted function type distinction
in BGGA.<br>
  <br>
Perhaps you'd like both of the lambda forms in 0.6a to have returns
treated locally, and add a third form that provides transparency?<br>
  </div>
  </div>
</blockquote>
Yes, I'm suggesting both of the lambda forms in 0.6a to have returns
treated locally, and then to have another way, either a third form or
variants of the other forms, that provide transparency.&nbsp; I phrase it
that way to try and emphasize that transparency seems to be an
othogonal property to the difference between expression and statement
lambdas.<br>
<br>
<blockquote
 cite="mid:15e8b9d20912151430k78061bb2j1f2726032269ee65@mail.gmail.com"
 type="cite">
  <div class="gmail_quote">
  <div><br>
  <div style="margin-left: 40px; font-family: courier new,monospace;"><b>#(
FormalParameters ) =&gt; ( </b><i><span
 style="font-family: arial,helvetica,sans-serif;">Statements<font
 size="1">opt</font> Expression </span></i><b>)<br>
  </b></div>
  <br>
As I pointed out previously, if we do that then we don't need block
expressions, and
we can use a slightly different lambda conversion for transparent
lambdas that allows boxing
and unboxing when matching lambda parameters to the interface function.<br>
  <br>
Cheers,<br>
Neal<br>
  <br>
  </div>
  </div>
</blockquote>
<br>
-- Jon<br>
</body>
</html>