Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Joshua Cranmer Newsgroups: comp.lang.java.programmer Subject: Re: new Java lambda syntax Date: Tue, 13 Sep 2011 15:22:24 -0500 Organization: A noiseless patient Spider Lines: 71 Message-ID: References: <9j3vj8-aqe.ln1@news.simpsonst.f2s.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 13 Sep 2011 20:23:01 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="WpcHJSul77m+zlbR9GVqkA"; logging-data="17438"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/T0tGnepyGtIcWRGYcWG6E0icTtG9nDxU=" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 In-Reply-To: Cancel-Lock: sha1:pyovN8IgcNt/NAG8mdIOYojyBo8= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:7985 On 9/13/2011 2:04 PM, Daniele Futtorovic wrote: > Okay, so you can have a lambda returning a value? Steve Simpson's statement: > >> There's no (...) long jumps (break, continue, return, throw) > > seemed to contradict that, as did Tom's about the "Gafterist nonsense" > (<3), seeing how Gafter et al.'s proposal contained return values, IIRC. What this is referring to is that lambdas do not have non-local control flow (the so-called "long jump" -- think about C's setjmp/longjmp feature [1]). Lambdas are effectively "mini-functions", so I could have a lambda that looked like this: (int[] x, int y) => { for (int i = 0; i < x.length; i++) if (x[i] == y) return i; return -1; }; which would effectively be a method that looked like: int searchList(int[] x, int y) { for (int i = 0; i < x.length; i++) if (x[i] == y) return i; return -1; } In other words, what was not accepted was the thing that pissed me off about some of the proposals, namely that any block of statements should do the exact same thing if you wrapped it with ((){/*insert stmt*/})() [2]. So this would return true: boolean foo() { ((){ return true; })(); return false; } Obviously, if you want to have more complex logic in the lambda for returning multiple values other than what you can do in a simple expression, you'd need some sort of syntax. The compromise then being discussed would make this method return false: boolean foo() { ((){ return true })(); return false; } ... It was at that point that I personally hated non-local control flow in closures, er, lambdas. [3] [1] Actually, don't. It breaks so many things. [2] This is, supposedly, Tennent's Correspondence Principle. I say supposedly since a google search only reveals results that are specifically brought up in reference to the closures debate in JS and Java. [3] Actually, doing some more research for this posting, it struck me that the primary rationale for non-local control flow comes from the heritage of lambdas. Most of the time, lambdas are used in reference to functional programming paradigms, and in the purer functional languages, control flow is not done via explicit constructs but rather via specific function calls. So it's a list.forEach( { body of loop }) as opposed to a for (Element e : list) { body of loop }; in such languages, non-local control flow is more important. However, given that Java is more imperatively structured than functionally structured, non-local control flow is by means no natural, nor is it necessary to implement, so I would still stand by my claim that non-local control flow is not a feature that should be implemented in Java's version of lambdas. For example, C++11 appears to omit it in their version of lambdas... -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth