From neal at gafter.com Tue Feb 2 08:02:02 2010 From: neal at gafter.com (Neal Gafter) Date: Tue, 2 Feb 2010 08:02:02 -0800 Subject: Preparing for the 0.2 draft In-Reply-To: <4B68129C.5000008@cs.oswego.edu> References: <4B62A2CE.7080300@sun.com> <4B67427D.9080608@sun.com> <4B677D4D.4030408@cs.oswego.edu> <15e8b9d21002012056t73d41a56we72d0d7de4f013c4@mail.gmail.com> <4B68129C.5000008@cs.oswego.edu> Message-ID: <15e8b9d21002020802j23154699n6ffb314555ca434a@mail.gmail.com> On Tue, Feb 2, 2010 at 3:55 AM, Doug Lea
wrote: >> that the kind of errors you're concerned about don't arise >> in practice. > > I don't think that we know very much about this. > There is very little experience out there with > extensive parallel usages of such constructs, and > those few parallel languages that include some form > of lambda/closure (including X10 and Fortress) do not > hoist scopes. [Moving conversation to closures-dev] I don't know whether you consider Scala a "parallel language", and one can argue whether or not its use has been "extensive", but there is little evidence that Scala's nonlocal transfers [or access to enclosing scopes, for that matter] have caused the kind of craziness you appear to be worried about. From markmahieu at googlemail.com Tue Feb 2 08:18:56 2010 From: markmahieu at googlemail.com (Mark Mahieu) Date: Tue, 2 Feb 2010 16:18:56 +0000 Subject: Preparing for the 0.2 draft In-Reply-To: <15e8b9d21002020802j23154699n6ffb314555ca434a@mail.gmail.com> References: <4B62A2CE.7080300@sun.com> <4B67427D.9080608@sun.com> <4B677D4D.4030408@cs.oswego.edu> <15e8b9d21002012056t73d41a56we72d0d7de4f013c4@mail.gmail.com> <4B68129C.5000008@cs.oswego.edu> <15e8b9d21002020802j23154699n6ffb314555ca434a@mail.gmail.com> Message-ID: <7891B134-A043-4745-AE0C-320CC189D8F9@googlemail.com> On 2 Feb 2010, at 16:02, Neal Gafter wrote: > On Tue, Feb 2, 2010 at 3:55 AM, Doug Lea
wrote: >>> that the kind of errors you're concerned about don't arise >>> in practice. >> >> I don't think that we know very much about this. >> There is very little experience out there with >> extensive parallel usages of such constructs, and >> those few parallel languages that include some form >> of lambda/closure (including X10 and Fortress) do not >> hoist scopes. > > [Moving conversation to closures-dev] > > I don't know whether you consider Scala a "parallel language", and one > can argue whether or not its use has been "extensive", but there is > little evidence that Scala's nonlocal transfers [or access to > enclosing scopes, for that matter] have caused the kind of craziness > you appear to be worried about. Out of interest, do you know how Scala's nonlocal transfers are implemented (roughly)? I must admit that BGGA's gave me the jitters before I understood how they would work, but they turned out to really quite mundane, and easy enough to reason about, diagnose problems etc. Mark From ricky.clarkson at gmail.com Tue Feb 2 08:20:28 2010 From: ricky.clarkson at gmail.com (Ricky Clarkson) Date: Tue, 2 Feb 2010 16:20:28 +0000 Subject: Preparing for the 0.2 draft In-Reply-To: <7891B134-A043-4745-AE0C-320CC189D8F9@googlemail.com> References: <4B62A2CE.7080300@sun.com> <4B67427D.9080608@sun.com> <4B677D4D.4030408@cs.oswego.edu> <15e8b9d21002012056t73d41a56we72d0d7de4f013c4@mail.gmail.com> <4B68129C.5000008@cs.oswego.edu> <15e8b9d21002020802j23154699n6ffb314555ca434a@mail.gmail.com> <7891B134-A043-4745-AE0C-320CC189D8F9@googlemail.com> Message-ID: <7eeb06461002020820w6526ecc1q5768c1708815d7a4@mail.gmail.com> They work the same way as BGGA's. Though only for return, as Scala has no break or continue. Thanks, Ricky. -- Ricky Clarkson Java and Scala Programmer, AD Holdings +44 1928 706373 Skype: ricky_clarkson Google Talk: ricky.clarkson at gmail.com Google Wave: ricky.clarkson at googlewave.com On 2 February 2010 16:18, Mark Mahieu wrote: > > On 2 Feb 2010, at 16:02, Neal Gafter wrote: > >> On Tue, Feb 2, 2010 at 3:55 AM, Doug Lea
wrote: >>>> that the kind of errors you're concerned about don't arise >>>> in practice. >>> >>> I don't think that we know very much about this. >>> There is very little experience out there with >>> extensive parallel usages of such constructs, and >>> those few parallel languages that include some form >>> of lambda/closure (including X10 and Fortress) do not >>> hoist scopes. >> >> [Moving conversation to closures-dev] >> >> I don't know whether you consider Scala a "parallel language", and one >> can argue whether or not its use has been "extensive", but there is >> little evidence that Scala's nonlocal transfers [or access to >> enclosing scopes, for that matter] have caused the kind of craziness >> you appear to be worried about. > > Out of interest, do you know how Scala's nonlocal transfers are implemented (roughly)? ?I must admit that BGGA's gave me the jitters before I understood how they would work, but they turned out to really quite mundane, and easy enough to reason about, diagnose problems etc. > > Mark > > From neal at gafter.com Sun Feb 7 09:10:47 2010 From: neal at gafter.com (Neal Gafter) Date: Sun, 7 Feb 2010 09:10:47 -0800 Subject: related link In-Reply-To: <7926817e1002070902h99c558s221685f1989b80d2@mail.gmail.com> References: <7926817e1002070902h99c558s221685f1989b80d2@mail.gmail.com> Message-ID: <15e8b9d21002070910x5326fd26o33ab126aabdd2d61@mail.gmail.com> Jesse- That article provides a good understanding of the goals of BGGA and CfJ 0.6a/b (and the openjdk closures project), as contrasted with the goals of the current effort (openjdk project lambda). Cheers, Neal On Sun, Feb 7, 2010 at 9:02 AM, Jesse Kuhnert wrote: > With no intention of implying that either language is close enough to > be compared directly, just that it's a lengthy analysis of the > subject matter here which might provide more mental fuel. > > http://yehudakatz.com/2010/02/07/the-building-blocks-of-ruby/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20100207/bb8d3882/attachment.html From john at milsson.nu Sun Feb 7 14:50:55 2010 From: john at milsson.nu (John Nilsson) Date: Sun, 7 Feb 2010 23:50:55 +0100 Subject: related link In-Reply-To: <15e8b9d21002070910x5326fd26o33ab126aabdd2d61@mail.gmail.com> References: <7926817e1002070902h99c558s221685f1989b80d2@mail.gmail.com> <15e8b9d21002070910x5326fd26o33ab126aabdd2d61@mail.gmail.com> Message-ID: It seems to me that project lambda fits better with, well, lambdas. The other goals would probably be better addressed with some static construct, like macros. BR, John On Sun, Feb 7, 2010 at 6:10 PM, Neal Gafter wrote: > Jesse- > > That article provides a good understanding of the goals of BGGA and CfJ > 0.6a/b (and the openjdk closures project), as contrasted with the goals of > the current effort (openjdk project lambda). > > Cheers, > Neal > > On Sun, Feb 7, 2010 at 9:02 AM, Jesse Kuhnert wrote: > > > With no intention of implying that either language is close enough to > > be compared directly, just that it's a lengthy analysis of the > > subject matter here which might provide more mental fuel. > > > > http://yehudakatz.com/2010/02/07/the-building-blocks-of-ruby/ > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20100207/0116b96b/attachment.html From neal at gafter.com Sun Feb 7 15:36:58 2010 From: neal at gafter.com (Neal Gafter) Date: Sun, 7 Feb 2010 15:36:58 -0800 Subject: related link In-Reply-To: References: <7926817e1002070902h99c558s221685f1989b80d2@mail.gmail.com> <15e8b9d21002070910x5326fd26o33ab126aabdd2d61@mail.gmail.com> Message-ID: <15e8b9d21002071536h9b1d58n29b5af89aa85dc61@mail.gmail.com> John- It hasn't been shown that a simple macro facility can support control constructs in a library in the absence of transparent closures (I'd welcome your attempt to do so). However, it has been shown that transparent closures are sufficient. Macros are nice in making the syntax of such control APIs more convenient; BGGA and CfJ 0.6b < http://www.javac.info/closures-v06b.html> address the convenience issue by supporting one particular but common special case (where a function is accepted by an API as its last parameter) rather than attempting to add a complete hygienic macro system. Cheers, Neal On Sun, Feb 7, 2010 at 2:50 PM, John Nilsson wrote: > It seems to me that project lambda fits better with, well, lambdas. > > The other goals would probably be better addressed with some static > construct, like macros. > > BR, > John > > On Sun, Feb 7, 2010 at 6:10 PM, Neal Gafter wrote: > >> Jesse- >> >> That article provides a good understanding of the goals of BGGA and CfJ >> 0.6a/b (and the openjdk closures project), as contrasted with the goals of >> the current effort (openjdk project lambda). >> >> Cheers, >> Neal >> >> On Sun, Feb 7, 2010 at 9:02 AM, Jesse Kuhnert wrote: >> >> > With no intention of implying that either language is close enough to >> > be compared directly, just that it's a lengthy analysis of the >> > subject matter here which might provide more mental fuel. >> > >> > http://yehudakatz.com/2010/02/07/the-building-blocks-of-ruby/ >> > >> > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20100207/db3ec4b1/attachment.html From john at milsson.nu Mon Feb 8 09:21:19 2010 From: john at milsson.nu (John Nilsson) Date: Mon, 8 Feb 2010 18:21:19 +0100 Subject: related link In-Reply-To: <15e8b9d21002071536h9b1d58n29b5af89aa85dc61@mail.gmail.com> References: <7926817e1002070902h99c558s221685f1989b80d2@mail.gmail.com> <15e8b9d21002070910x5326fd26o33ab126aabdd2d61@mail.gmail.com> <15e8b9d21002071536h9b1d58n29b5af89aa85dc61@mail.gmail.com> Message-ID: In my, admittedly rather na?ve, mind such a static construct could be modelled as transparent closures with the added restriction that it is to in-lined at compile time, and as such would disallow any treatment of them as run-time constructs. F.ex. moving references around would be a static error. The rather narrow goal in my mind being to allow "non-local returns" without the scary stuff ;) When you said "has been shown" did you have any particular paper in mind? (I'm rather curious about PL-research) BR, John On Mon, Feb 8, 2010 at 12:36 AM, Neal Gafter wrote: > John- > > It hasn't been shown that a simple macro facility can support control > constructs in a library in the absence of transparent closures (I'd welcome > your attempt to do so). However, it has been shown that transparent > closures are sufficient. Macros are nice in making the syntax of such > control APIs more convenient; BGGA and CfJ 0.6b < > http://www.javac.info/closures-v06b.html> address the convenience issue by > supporting one particular but common special case (where a function is > accepted by an API as its last parameter) rather than attempting to add a > complete hygienic macro system. > > Cheers, > Neal > > > On Sun, Feb 7, 2010 at 2:50 PM, John Nilsson wrote: > >> It seems to me that project lambda fits better with, well, lambdas. >> >> The other goals would probably be better addressed with some static >> construct, like macros. >> >> BR, >> John >> >> On Sun, Feb 7, 2010 at 6:10 PM, Neal Gafter wrote: >> >>> Jesse- >>> >>> That article provides a good understanding of the goals of BGGA and CfJ >>> 0.6a/b (and the openjdk closures project), as contrasted with the goals >>> of >>> the current effort (openjdk project lambda). >>> >>> Cheers, >>> Neal >>> >>> On Sun, Feb 7, 2010 at 9:02 AM, Jesse Kuhnert >>> wrote: >>> >>> > With no intention of implying that either language is close enough to >>> > be compared directly, just that it's a lengthy analysis of the >>> > subject matter here which might provide more mental fuel. >>> > >>> > http://yehudakatz.com/2010/02/07/the-building-blocks-of-ruby/ >>> > >>> > >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20100208/32c46b09/attachment.html From neal at gafter.com Mon Feb 8 11:03:42 2010 From: neal at gafter.com (Neal Gafter) Date: Mon, 8 Feb 2010 11:03:42 -0800 Subject: related link In-Reply-To: References: <7926817e1002070902h99c558s221685f1989b80d2@mail.gmail.com> <15e8b9d21002070910x5326fd26o33ab126aabdd2d61@mail.gmail.com> <15e8b9d21002071536h9b1d58n29b5af89aa85dc61@mail.gmail.com> Message-ID: <15e8b9d21002081103x91d3371h72b41d46c8dbe05f@mail.gmail.com> On Mon, Feb 8, 2010 at 9:21 AM, John Nilsson wrote: > In my,?admittedly?rather na?ve, mind such a static construct could > be?modelled?as transparent?closures with the added restriction that it is to > in-lined at compile time, and as such would disallow any treatment of them > as run-time constructs. F.ex. moving references around would be a static > error. > The rather narrow goal in my mind being to allow "non-local returns" without > the scary stuff ;) > When you said "has been shown" did you have any particular paper in mind? > (I'm rather curious about PL-research) > BR, > John John- If you want to continue this discussion, please join the closures-dev mailing list. Inlining at compile-time only works for very restricted kinds of APIs, and excludes many interesting and useful APIs that could be written using transparent lambdas. See, for example, my blog post on concurrent loops , which has been implemented by Mark Mahieu . That is just not possible with the approach you suggest. Inlining also undermines binary compatibility, which is one of Java's strengths. FYI, experience with languages that support "non-local return" (Scala, Ruby, etc) has resulted in a remarkable absence of scary things happening. They're really quite boring and ordinary once you try them. For writings about the expressive power of transparent lambdas, one place to start would be Steele and Sussman's 1970's "Lambda the Ultimate..." papers . From john at milsson.nu Mon Feb 8 14:45:12 2010 From: john at milsson.nu (John Nilsson) Date: Mon, 8 Feb 2010 23:45:12 +0100 Subject: related link In-Reply-To: <15e8b9d21002081103x91d3371h72b41d46c8dbe05f@mail.gmail.com> References: <7926817e1002070902h99c558s221685f1989b80d2@mail.gmail.com> <15e8b9d21002070910x5326fd26o33ab126aabdd2d61@mail.gmail.com> <15e8b9d21002071536h9b1d58n29b5af89aa85dc61@mail.gmail.com> <15e8b9d21002081103x91d3371h72b41d46c8dbe05f@mail.gmail.com> Message-ID: On Mon, Feb 8, 2010 at 8:03 PM, Neal Gafter wrote: > If you want to continue this discussion, please join the closures-dev > mailing list. > done > Inlining at compile-time only works for very restricted kinds of APIs, > and excludes many interesting and useful APIs that could be written > using transparent lambdas. See, for example, my blog post on > concurrent loops > < > http://gafter.blogspot.com/2006/10/concurrent-loops-using-java-closures.html > >, > A quick and dirty pretend syntax (didn't really spend too much time thinking about concurrency, but I'm assuming that any issues can be address within the macro construct). I'm assuming some kind of name-mangling for the names introduced by the macro, except for the ones supplied by the caller which are simply inserted at the obvious places. public macro forEachConcurrently(T retT : Iterable iter, ExecutorService threadPool) {void} block { final Collection> tasks = new ArrayList>(); final Collection> futures = new ArrayList(); for(final T t : iter) { tasks.add(Executors.callable(new Runnable(){public void run() { try { retT = t; block; } continue { //Noop } break { for(Future f : futures) f.cancel(); } return { for(Future f : futures) f.cancel(); } }})); } try { futures.addAll(threadPool.invokeAll(tasks)); } catch (InterruptedException ex) {} } > which has been implemented by Mark Mahieu > . > That is just not possible with the approach you suggest. Inlining > also undermines binary compatibility, which is one of Java's > strengths. > Hmm. I don't think I see the problem. > FYI, experience with languages that support "non-local return" (Scala, > Ruby, etc) has resulted in a remarkable absence of scary things > happening. They're really quite boring and ordinary once you try > them. > I guess you are right. But I still feel uneasy about it. The current closure semantics of java allows me to think (am I wrong?) that the stack frame and everything related to it will be completely forgotten once the method returns. What happens to stack frames to which we can return from closures that has been saved away? Is it saved away as a continuation? Are they garbage collected? Will lots of deeply nested calls pollute my heap if I don't allow the lambdas to get garbage collected? Do I need to worry about these things? For writings about the expressive power of transparent lambdas, one > place to start would be Steele and Sussman's 1970's "Lambda the > Ultimate..." papers > < > http://en.wikipedia.org/wiki/History_of_the_Scheme_programming_language#The_Lambda_Papers > >. > Thanks for the pointer! BR, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20100208/b7483539/attachment.html From neal at gafter.com Mon Feb 8 15:34:57 2010 From: neal at gafter.com (Neal Gafter) Date: Mon, 8 Feb 2010 15:34:57 -0800 Subject: related link In-Reply-To: References: <7926817e1002070902h99c558s221685f1989b80d2@mail.gmail.com> <15e8b9d21002070910x5326fd26o33ab126aabdd2d61@mail.gmail.com> <15e8b9d21002071536h9b1d58n29b5af89aa85dc61@mail.gmail.com> <15e8b9d21002081103x91d3371h72b41d46c8dbe05f@mail.gmail.com> Message-ID: <15e8b9d21002081534n30253382t60347a2bf5546295@mail.gmail.com> On Mon, Feb 8, 2010 at 2:45 PM, John Nilsson wrote: > On Mon, Feb 8, 2010 at 8:03 PM, Neal Gafter wrote: > A quick and dirty pretend syntax (didn't really spend too much time thinking > about concurrency, but I'm assuming that any issues can be address within > the macro construct). The problem isn't syntax, it's semantics. I don't see how your API makes return/break/continue "do the right thing" from the API client's point of view. You seem to treat break and return identically, for example, but they don't have the same meaning at all. >> FYI, experience with languages that support "non-local return" (Scala, >> Ruby, etc) has resulted in a remarkable absence of scary things >> happening. ?They're really quite boring and ordinary once you try >> them. > > I guess you are right. But I still feel uneasy about it. The current closure > semantics of java allows me to think (am I wrong?) that the stack frame and > everything related to it will be completely forgotten once the method > returns. Yes, that's also the way it works in BGGA (and Scala, Ruby, etc). > What happens to stack frames to which we can return from closures > that has been saved away? The same thing that always happened to it. When you return from a method its stack frame goes away. Captured (local) variables might survive, though, just as they do with anonymous inner classes and project lambda. > Is it saved away as a continuation? Nope. That's an interesting alternative but nobody has proposed it, and I don't think it works out well in Java. > Are they > garbage collected? Will lots of deeply nested calls pollute my heap if I > don't allow the lambdas to get garbage collected? Do I need to worry about > these things? Nope. They just go away when you return from the method. From John.Rose at Sun.COM Tue Feb 9 11:22:24 2010 From: John.Rose at Sun.COM (John Rose) Date: Tue, 09 Feb 2010 11:22:24 -0800 Subject: related link In-Reply-To: <15e8b9d21002081103x91d3371h72b41d46c8dbe05f@mail.gmail.com> References: <7926817e1002070902h99c558s221685f1989b80d2@mail.gmail.com> <15e8b9d21002070910x5326fd26o33ab126aabdd2d61@mail.gmail.com> <15e8b9d21002071536h9b1d58n29b5af89aa85dc61@mail.gmail.com> <15e8b9d21002081103x91d3371h72b41d46c8dbe05f@mail.gmail.com> Message-ID: On Feb 8, 2010, at 11:03 AM, Neal Gafter wrote: > FYI, experience with languages that support "non-local return" (Scala, > Ruby, etc) has resulted in a remarkable absence of scary things > happening. They're really quite boring and ordinary once you try > them. ...and Lisp, Smalltalk. The experience with such constructs spans almost the entire history of software. People who've actually used such constructs are not afraid of them. The experience of Ruby particularly shows the chaos you get into when you come to the "return" fork and take both sides: Now they have multiple constructs that handle "return" differently, and they are having to back and fill (in 1.9) to rationalize the mess. The Python designers were wiser and restricted closure bodies to simple expressions, to dodge the "return" question completely. Regarding "scariness": Given any language extension proposal, a significant number of people (not just a few) will be vocally afraid of the unknown effects of the proposal. Of those who were excited enough to comment on Inner Classes in 1.1, about 30% accused us of ruining Java. Some still think so, probably, but on the whole it doesn't matter. For most people, the unknown eventually became the known, and it was (to everyone's relief) a livable reality. Regarding the specific dangers of uplevel branch: An unmatched uplevel branch, which causes an exception when executed, is annoyingly dynamic. It is self-diagnosing, exactly like a NPE or CCE. And BGGA has a novel static check for restricting branches to appropriate APIs, so there's a static story too, unlike NPE or CCE. And (as those who have used such things know by experience) the problem comes up much less often than NPE or CCE does in Java. Compared with the largely-hypothetical dangers of uplevel branches, I am personally much more afraid, based on experience with Lisp, of unexpected, undiagnosed effects of the "dotimes bug"[1] with captured mutable locals. -- John [1] http://blogs.msdn.com/ericlippert/archive/2009/11/12/closing-over-the-loop-variable-considered-harmful.aspx See also my comment on that web page. From john at milsson.nu Tue Feb 9 12:21:41 2010 From: john at milsson.nu (John Nilsson) Date: Tue, 9 Feb 2010 21:21:41 +0100 Subject: related link In-Reply-To: References: <7926817e1002070902h99c558s221685f1989b80d2@mail.gmail.com> <15e8b9d21002070910x5326fd26o33ab126aabdd2d61@mail.gmail.com> <15e8b9d21002071536h9b1d58n29b5af89aa85dc61@mail.gmail.com> <15e8b9d21002081103x91d3371h72b41d46c8dbe05f@mail.gmail.com> Message-ID: On Tue, Feb 9, 2010 at 8:22 PM, John Rose wrote: > Regarding the specific dangers of uplevel branch: An unmatched uplevel > branch, which causes an exception when executed, is annoyingly dynamic. It > is self-diagnosing, exactly like a NPE or CCE. And BGGA has a novel static > check for restricting branches to appropriate APIs, so there's a static > story too, unlike NPE or CCE. And (as those who have used such things know > by experience) the problem comes up much less often than NPE or CCE does in > Java. > I had assumed, wrongly I now discover, that the return would always succeed, whatever that meant. Throwing an exception feels safe enough for me. =) "Annoyingly dynamic" is a perfect description of how I feel about that. It does strike me that it creates two classes of lambda consumers. Those which it is safe to use control transfer with, and those that it isn't. Will this introduce problems for APIs that accidentally belongs to one class and later want to migrate to the other class? Compared with the largely-hypothetical dangers of uplevel branches, I am > personally much more afraid, based on experience with Lisp, of unexpected, > undiagnosed effects of the "dotimes bug"[1] with captured mutable locals. > Given the UnmatchedTransferException solution I'm in full agreement. I like the current Java requirement that variables need to be final. I could live with a design where non-final variables would be shadowed by final versions implicitly introduced within the lambda-body. This would solve some annoying cases where it would be easier to use variables outside the lambda body. Intuitively I like to think that a closure closes over values, not names, they are just automatically bound to the same names within the closure. But I guess I can always be re-trained if needed. BR, John p.s. unless it seems to off topic I'd still like to work out the edges of my macro suggestion because I still feel that some things are "annoyingly dynamic" ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20100209/3f6240fd/attachment.html From john at milsson.nu Tue Feb 9 12:51:32 2010 From: john at milsson.nu (John Nilsson) Date: Tue, 9 Feb 2010 21:51:32 +0100 Subject: related link In-Reply-To: <15e8b9d21002081534n30253382t60347a2bf5546295@mail.gmail.com> References: <7926817e1002070902h99c558s221685f1989b80d2@mail.gmail.com> <15e8b9d21002070910x5326fd26o33ab126aabdd2d61@mail.gmail.com> <15e8b9d21002071536h9b1d58n29b5af89aa85dc61@mail.gmail.com> <15e8b9d21002081103x91d3371h72b41d46c8dbe05f@mail.gmail.com> <15e8b9d21002081534n30253382t60347a2bf5546295@mail.gmail.com> Message-ID: On Tue, Feb 9, 2010 at 12:34 AM, Neal Gafter wrote: > On Mon, Feb 8, 2010 at 2:45 PM, John Nilsson wrote: > > On Mon, Feb 8, 2010 at 8:03 PM, Neal Gafter wrote: > > A quick and dirty pretend syntax (didn't really spend too much time > thinking > > about concurrency, but I'm assuming that any issues can be address within > > the macro construct). > > The problem isn't syntax, it's semantics. I don't see how your API > makes return/break/continue "do the right thing" from the API client's > point of view. You seem to treat break and return identically, for > example, but they don't have the same meaning at all. > The idea behind the try syntax thing was that the macro would inject the code blocks at the points where the client used break/continue/return but keep the actual control transfer (in relation to the defined block). A slight modification to standard Java might be required to allow breaks and continues from any block. Both break and continue jumps to the end of the block and triggers the behaviour specified by the macro. return returns from the method where the block was declared but triggers the trapped behaviour. Using the try-syntax I was trying to appeal to the known semantics of finally-clauses. BR, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20100209/159942e1/attachment.html From neal at gafter.com Tue Feb 9 13:05:26 2010 From: neal at gafter.com (Neal Gafter) Date: Tue, 9 Feb 2010 13:05:26 -0800 Subject: related link In-Reply-To: References: <7926817e1002070902h99c558s221685f1989b80d2@mail.gmail.com> <15e8b9d21002070910x5326fd26o33ab126aabdd2d61@mail.gmail.com> <15e8b9d21002071536h9b1d58n29b5af89aa85dc61@mail.gmail.com> <15e8b9d21002081103x91d3371h72b41d46c8dbe05f@mail.gmail.com> <15e8b9d21002081534n30253382t60347a2bf5546295@mail.gmail.com> Message-ID: <15e8b9d21002091305y1175ed1ej27cb15e89d74723e@mail.gmail.com> On Tue, Feb 9, 2010 at 12:51 PM, John Nilsson wrote: > The idea behind the try syntax thing was that the macro would inject the > code blocks at the points where the client used break/continue/return but > keep the actual control transfer (in relation to the defined block). A > slight modification to standard Java might be required to allow breaks and > continues from any block. > > Both break and continue jumps to the end of the block and triggers the > behaviour specified by the macro. return returns from the method where the > block was declared but triggers the trapped behaviour. > > Using the try-syntax I was trying to appeal to the known semantics of > finally-clauses. > I think it would be instructive to see how the concurrent loop would work. < http://gafter.blogspot.com/2006/10/concurrent-loops-using-java-closures.html > How would you do this using the macro scheme? -Neal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20100209/4a83f8f3/attachment.html From john at milsson.nu Tue Feb 9 13:52:04 2010 From: john at milsson.nu (John Nilsson) Date: Tue, 9 Feb 2010 22:52:04 +0100 Subject: related link In-Reply-To: <15e8b9d21002091305y1175ed1ej27cb15e89d74723e@mail.gmail.com> References: <7926817e1002070902h99c558s221685f1989b80d2@mail.gmail.com> <15e8b9d21002070910x5326fd26o33ab126aabdd2d61@mail.gmail.com> <15e8b9d21002071536h9b1d58n29b5af89aa85dc61@mail.gmail.com> <15e8b9d21002081103x91d3371h72b41d46c8dbe05f@mail.gmail.com> <15e8b9d21002081534n30253382t60347a2bf5546295@mail.gmail.com> <15e8b9d21002091305y1175ed1ej27cb15e89d74723e@mail.gmail.com> Message-ID: On Tue, Feb 9, 2010 at 10:05 PM, Neal Gafter wrote: > How would you do this using the macro scheme? > Given the macro I previously defined. The following would be expanded as below. But you were right, it was quite instructive. What does it mean to return concurrently? I guess the right thing to do is to change the macro to block the first thread waiting for the futures and return from there. public Collection getAttendees() { List result = new ArrayList(); forEachConcurrently(EventResponse r : getResponses(), threadPool) { if (r.mayAttend()) { Principal attendee = r.getAttendee(); synchronized (result) { result.add(attendee); } } } return result; } public Collection getAttendees() { List result = new ArrayList(); final Collection> tasks = new ArrayList>(); final Collection> futures = new ArrayList(); for(final EventResponse t : getResponses()) { tasks.add(Executors.callable(new Runnable(){public void run() { EventResponse r = t; //Slight bug in the macro, should be 'T retT' not just 'retT' forEachConcurrently_1234: { if (r.mayAttend()) { Principal attendee = r.getAttendee(); synchronized (result) { result.add(attendee); } } } }})); } try { futures.addAll(threadPool.invokeAll(tasks)); } catch (InterruptedException ex) {} return result; } BR, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20100209/ec0c12bd/attachment-0001.html From neal at gafter.com Tue Feb 9 13:55:11 2010 From: neal at gafter.com (Neal Gafter) Date: Tue, 9 Feb 2010 13:55:11 -0800 Subject: related link In-Reply-To: References: <7926817e1002070902h99c558s221685f1989b80d2@mail.gmail.com> <15e8b9d21002071536h9b1d58n29b5af89aa85dc61@mail.gmail.com> <15e8b9d21002081103x91d3371h72b41d46c8dbe05f@mail.gmail.com> <15e8b9d21002081534n30253382t60347a2bf5546295@mail.gmail.com> <15e8b9d21002091305y1175ed1ej27cb15e89d74723e@mail.gmail.com> Message-ID: <15e8b9d21002091355s6ff900bfwfc40bc5b0558307a@mail.gmail.com> On Tue, Feb 9, 2010 at 1:52 PM, John Nilsson wrote: > On Tue, Feb 9, 2010 at 10:05 PM, Neal Gafter wrote: > >> How would you do this using the macro scheme? >> > > Given the macro I previously defined. The following would be expanded as > below. But you were right, it was quite instructive. What does it mean to > return concurrently? I guess the right thing to do is to change the macro to > block the first thread waiting for the futures and return from there. > I don't see how your macro will do that. I don't see how you're going to make return work, or break or continue, or labeled break or labeled continue to particular enclosing loops or labelled statements. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20100209/7a8632d1/attachment.html From vladimir.kirichenko at gmail.com Wed Feb 10 05:56:00 2010 From: vladimir.kirichenko at gmail.com (Vladimir Kirichenko) Date: Wed, 10 Feb 2010 15:56:00 +0200 Subject: Syntax Again Message-ID: <4B72BAF0.7070909@gmail.com> Hi, All I have a question: why BGGA 0.5 syntax was rejected in favor of CLang-like syntax that causes so lots of problems? It much more elegant for function type definition #(#int(String)(throws IOException)) (String)(throws SQLException) vs {String => {String => int throws IOException} throws SQLException} The second one much more elegant and does not introduce #. -- Best Regards, Vladimir Kirichenko -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature Url : http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20100210/9bf54f34/attachment.bin From fredrik.ohrstrom at oracle.com Wed Feb 10 06:41:07 2010 From: fredrik.ohrstrom at oracle.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Wed, 10 Feb 2010 15:41:07 +0100 Subject: Syntax Again In-Reply-To: <4B72BAF0.7070909@gmail.com> References: <4B72BAF0.7070909@gmail.com> Message-ID: <4B72C583.2040803@oracle.com> Somehow I think that no official looking body has explicitly rejected the BGGA syntax. It has more sort of been left in limbo. Personally I consider it important to easily discern between a Type and a piece of code. Thus the creation of a closure is excellent in the BGGA proposal, and it looks like a bit of code, which is perfect since an important purpose of BGGA is control abstraction. However the type holding on to the closure also looks like a piece of code, this is not so good. Integers (1234) do not look like "int". The closure type need not look like the actual closure creation body. //Fredrik Vladimir Kirichenko skrev: > Hi, All > > I have a question: why BGGA 0.5 syntax was rejected in favor of > CLang-like syntax that causes so lots of problems? > > It much more elegant for function type definition > > #(#int(String)(throws IOException)) (String)(throws SQLException) > > vs > > {String => {String => int throws IOException} throws SQLException} > > The second one much more elegant and does not introduce #. > > From forax at univ-mlv.fr Wed Feb 10 06:59:49 2010 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Wed, 10 Feb 2010 15:59:49 +0100 Subject: Syntax Again In-Reply-To: <4B72C583.2040803@oracle.com> References: <4B72BAF0.7070909@gmail.com> <4B72C583.2040803@oracle.com> Message-ID: <4B72C9E5.2040704@univ-mlv.fr> Le 10/02/2010 15:41, Fredrik ?hrstr?m a ?crit : > Somehow I think that no official looking body has explicitly rejected > the BGGA syntax. It has more sort of been left in limbo. > > Personally I consider it important to easily discern between a Type and > a piece of code. > Thus the creation of a closure is excellent in the BGGA proposal, and it > looks like > a bit of code, which is perfect since an important purpose of BGGA is > control abstraction. > > However the type holding on to the closure also looks like a piece of > code, this is not so good. > Integers (1234) do not look like "int". The closure type need not look > like the actual closure > creation body. > > //Fredrik > +1 R?mi From vladimir.kirichenko at gmail.com Wed Feb 10 07:20:39 2010 From: vladimir.kirichenko at gmail.com (Vladimir Kirichenko) Date: Wed, 10 Feb 2010 17:20:39 +0200 Subject: Syntax Again In-Reply-To: <4B72C583.2040803@oracle.com> References: <4B72BAF0.7070909@gmail.com> <4B72C583.2040803@oracle.com> Message-ID: <4B72CEC7.7000903@gmail.com> Fredrik ?hrstr?m wrote: > Somehow I think that no official looking body has explicitly rejected > the BGGA syntax. It has more sort of been left in limbo. But a lot of time wasted in discussions of actual #-based syntax. Even JLS proposal has been started. A lots of people discussing where to put #, how to wrap "throws" in braces, and how to !*.invoke function. I do not understand the process so. -- Best Regards, Vladimir Kirichenko -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature Url : http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20100210/7c4d67e4/attachment.bin