Y combinator using lambda and method references

Brian Goetz brian.goetz at oracle.com
Sun Oct 28 06:27:32 PDT 2012


Folks, a request -- go easy on IDE vendors on this stuff.  They are 
valiently trying to track early draft specs, but for things that are in 
flux, such as inference, we don't want to waste a lot of their time 
changing things that they're just going to have to change again when the 
spec stabilizes.  The last thing we want is for next time around, for 
them to say "we'll wait until the spec is final before we start on it."

On 10/28/2012 8:17 AM, Ricky Clarkson wrote:
> I reported some bugs against IDEA that look like what you saw.  I'd wait
> for the next EAP (after 122.639) before reporting, my bugs got fixed but
> not in time for 122.639
>
> On Oct 27, 2012 7:15 PM, "Arul Dhesiaseelan" <aruld at acm.org
> <mailto:aruld at acm.org>> wrote:
>
>     Ah, that makes sense, it was just curiosity rather than application.
>     Thanks
>     Brian for the cooler version of YC.
>
>     On Sat, Oct 27, 2012 at 11:55 AM, Brian Goetz
>     <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>>wrote:
>
>      > The inference rules are still under development so it is not
>     surprising
>      > that the IDE and the static compiler do not yet agree.  When the spec
>      > settles, hopefully both will agree :)
>      >
>      >
>      > On 10/27/2012 5:20 PM, Arul Dhesiaseelan wrote:
>      >
>      >> I attempted to port this Y combinator [1] using Java 8 lambdas. The
>      >> closest
>      >> I can make it work is shown here [2].
>      >>
>      >> It looks like intellij code inspection suggests I can still
>     reduce this
>      >> further by using 2 method references and 1 lambda as shown
>     visually here
>      >> [3], but I run into problems with those conversions.
>      >>
>      >> # 1 Applying the first inspection (line # 19) to a method
>     reference fails
>      >> in a compile error:
>      >> error: cannot find symbol variable f
>      >>
>      >> #2 Applying the second inspection (line # 22) to a method reference
>      >> compiles just fine, but runs into a StackOverflowError. May be
>     this is a
>      >> problem with the code itself.
>      >>
>      >> #3 Applying the third inspection (line # 31) to a lambda fails in a
>      >> compile
>      >> error:
>      >>
>      >> error: method Y in class YFact cannot be applied to given types;
>      >> required: Func<Func<T>>
>      >> found: (final Fun[...] - 1)
>      >> reason: cyclic inference - cannot infer target type for given
>      >> lambda/method
>      >> reference expression
>      >> where T is a type-variable:
>      >> T extends Object declared in method <T>Y(Func<Func<T>>)
>      >>
>      >> I am not sure if this is a case where the editor is incorrect in
>     detecting
>      >> compilation errors. I believe the editor should reject these if the
>      >> compiler cannot infer the target type.
>      >>
>      >> Please apologize if this does not belong here.
>      >>
>      >> - Arul
>      >>
>      >> [1]
>     http://www.arcfn.com/2009/03/**y-combinator-in-arc-and-java.**html<http://www.arcfn.com/2009/03/y-combinator-in-arc-and-java.html>
>      >> [2] https://gist.github.com/**3965968
>     <https://gist.github.com/3965968>
>      >> [3]
>     https://dl.dropbox.com/u/**3274664/java/yfact-idea-**inspections.png<https://dl.dropbox.com/u/3274664/java/yfact-idea-inspections.png>
>      >>
>      >>
>


More information about the lambda-dev mailing list