Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: Steven Simpson Newsgroups: comp.lang.java.programmer Subject: Re: new Java lambda syntax Date: Sat, 10 Sep 2011 16:17:41 +0100 Organization: Aioe.org NNTP Server Lines: 44 Message-ID: References: NNTP-Posting-Host: r+C7JLFxs5GRD6HZueZLYg.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 X-Notice: Filtered by postfilter v. 0.8.2 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:7770 On 10/09/11 14:48, Tom Anderson wrote: > Did all that appalling lambda-transparency Gafterist nonsense get > ditched or enshrined? My understanding is that the problem scope has been gradually whittled down to 'potentially concurrent' APIs, i.e. where a method's contract does not make the guarantee that all calls to a supplied lambda will be on the method caller's thread, or that they will all finish before the method call returns. These are the sorts of guarantees you'd need to do control abstraction or event-driven coding, which in turn need the extra transparencies. I think the only transparencies that exist now are: * 'effectively final' - A non-final local variable can be immutably captured by a lambda, so long as it's shown not to be assigned to subsequently. * 'long this' - In the body of a lambda, 'this' has the same meaning as it would in the enclosing scope. It does not refer to the object that ultimately fulfils the lambda. * 'throws T' - A set of exceptions can be expressed as a generic type parameter, so they can be relayed from the lambda's signature to the signature of the method that calls it. There's no mutable local capture, or long jumps (break, continue, return, throw). I'd like to have seen such things, but I've come to agree that they shouldn't exist generally in lambdas. It could be argued that these restrictions seem to reduce lambdas to just a shorter syntax for certain anonymous inner classes. However, I think there's an aspiration to implement them more cheaply than normal objects. > Did that weird stuff about automatic conversion to single-method > interfaces make it through? There are no automatically generated families of function types (yet), so you have to rely on SAM (single abstract method) types. Lambdas are just a syntactic construct until you've expressed or implied the SAM type, with an assignment, initialization or a cast. -- ss at comp dot lancs dot ac dot uk