necessary information is never considered by inference?

[Anna Kozlova]

With the example from a bug https://bugs.openjdk.java.net/browse/JDK-8033488:

class Test {
    <T,R> R apply(Function<T,R> f, T arg) { return null; }

    {
        apply(a1 -> a1.length(), apply (a2-> a2.getMessage(), new RuntimeException("foo")));
    }
}

Exception constraint for "apply (a2-> a2.getMessage(), new RuntimeException("foo"))" is reduced before expression constraint "a2-> a2.getMessage()" because it doesn't produce any input variables. Is it a correct order?

Thanks,
Anna

-----Original Message-----
From: lambda-spec-observers-bounces at openjdk.java.net [mailto:lambda-spec-observers-bounces at openjdk.java.net] On Behalf Of Dan Smith
Sent: Tuesday, February 04, 2014 12:45 AM
To: Stephan Herrmann
Cc: lambda-spec-experts at openjdk.java.net
Subject: Re: necessary information is never considered by inference?

On Jan 31, 2014, at 5:39 PM, Dan Smith <daniel.smith at oracle.com> wrote:

> On Jan 28, 2014, at 4:33 AM, Stephan Herrmann <stephan.herrmann at berlin.de> wrote:
> 
>> Consider this example:
>> 
>> import java.util.stream.Stream;
>> import java.util.*;
>> import static java.util.stream.Collectors.collectingAndThen;
>> import static java.util.stream.Collectors.toList;
>> public class X {
>> 	void test(Stream<List<Integer>> stream) {
>> 		stream.collect(collectingAndThen(toList(), Collections::unmodifiableList))
>> 			.remove(0);
>> 	}
>> }
>> 
>> I fail to see anything in the spec that would let us determine the 
>> return type of the collect(..) invocation. Hence the remove() call 
>> would be unresolvable.
>> 
>> Given that javac does accept the program, I'm wondering what's 
>> causing this discrepancy.
>> 
>> We have two inference variables from the outer invocation, let's write it as:
> 
> ...
> 
>> However, I don't see where the spec would allow me to introduce such 
>> constraints: we're reducing this constraint:
>> ⟨collectingAndThen(toList(), Collections::unmodifiableList) → 
>> Collector<? super List<Integer>,A#1,R#0>⟩ for this reduction 18.2.1 instructs me to apply 18.5.2 for computing B3.
>> The problem is: computation of B3 only comprise those parts of 18.5.2 
>> that never touch the argument expressions, those come into the picture only after.
> 
> Yes, this is the crux of the problem.  The nested invocation's method reference is irrelevant to invocation typing in the spec, but javac is using it.  I believe javac captures the intended behavior; I'm now revisiting the design discussions about this to figure out what's supposed to happen.

See the bug tracker here:
https://bugs.openjdk.java.net/browse/JDK-8033488

The solution is simply to collect nested nested invocation arguments that were not pertinent to applicability when the set of remaining constraints, C, is assembled.  (We also need to collect 'throws' constraints from all nested arguments that are lambdas/method refs.)  Then they participate in the dependency analysis, just like everything else.

—Dan
!DSPAM:35,52f02a8f247165746062914!