Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Steven Simpson Newsgroups: comp.lang.java.programmer Subject: Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Date: Fri, 04 Jan 2013 23:45:54 +0000 Organization: A noiseless patient Spider Lines: 41 Message-ID: References: <9f030e71-96ab-4ead-9690-4369f4a19aa9@googlegroups.com> <0680c1e0-16cb-4791-8a5f-95a3ff2bcba8@googlegroups.com> <9t7503ltp93d.t74qawj4roq7.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: mx04.eternal-september.org; posting-host="0d771e3708e29ef01409ed69429633ae"; logging-data="16569"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19P+pL6i3Hqf9cQkUMpEPbC131muHw4e5I=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 In-Reply-To: <9t7503ltp93d.t74qawj4roq7.dlg@40tude.net> Cancel-Lock: sha1:oZRbvd/UWwEWPFCVxOMPG7Qo2WY= Xref: csiph.com comp.lang.java.programmer:20957 On 04/01/13 22:38, Peter Duniho wrote: > I can't speak for the previous poster. But clearly, closures don't do > anything you _can't_ do using lambdas or even using some other technique. > > The point is convenience, expressiveness, readability, and other code > authoring and maintenance such as may be of concern are affected. In the > view of closure proponents (such as my own), these concerns are addressed > in a positive way when closures are available. Indeed. I'm interested in seeing how much expressiveness (etc) is lost when one is forced to work around the lack of a feature, by looking at specific cases. > But that's the point: lambdas, closures, etc. offer a more concise, > expressive way of representing certain algorithm approaches. In this > context, I can confirm that there are plenty of examples of situations > where a true closure offers a more convenient, improved way of achieving > the same desired result, as compared to language syntax without closures. Do these examples fall into just a couple of categories, in terms of the guarantees that the user of a function object makes to the provider about how it will be invoked?: 1. The object will be invoked on the same thread that provided it (e.g. in an event-driven environment) 2. (1) + the object will not be invoked once the call that provided it has completed (e.g. in control abstraction) ...or are there more, especially ones which make fewer or alternative guarantees? I'm genuinely interested to see if there are more categories. Then, if they are limited, could a set of type qualifiers express these guarantees formally, and allow compilers to progressively switch on features like mutable local capture and various transparencies safely? -- ss at comp dot lancs dot ac dot uk