Playing with new compiler

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Thu Jun 2 01:45:03 PDT 2011


On 02/06/11 09:24, Maurizio Cimadamore wrote:
> On 02/06/11 04:52, Ali Ebrahimi wrote:
>> Hi Maurizio,
>> Is not this ambiguous?
> This one should - but your original example contained a cast to Object,
> which made the first candidate inapplicable.
I double checked and this one is not an issue. The compiler is rejecting 
the candidate:

      static interface SAM<R,A>   {
          R m(A n);
     }


because of cyclic type-inference (i.e. the types of the lambda 
parameters are not fully known before the body of the lambda can be 
attributed). As a result, the above candidate is not considered as 
applicable (try removing the other candidate and see the compile-time 
error).

As I said yesterday, it is possible that we will enhance type-inference 
to eagerly instantiate inference-variables in case of cyclic inference - 
in such case you will have the ambiguity, as both candidate will become 
applicable.

Maurizio
> Maurizio
>> call(#{ x ->   System.out.println(x);  return null; }); //prints
>> "SAM1" ?????
>> Candidates:  SAM<R,A>, SAM1
>>      static interface SAM1 {
>>           String m1(Integer n);
>>      }
>>
>>       static interface SAM<R,A>   {
>>           R m(A n);
>>      }
>>
>> Best Regards,
>> Ali Ebrahimi
>>
>> On Wed, Jun 1, 2011 at 7:44 PM, Maurizio Cimadamore
>> <maurizio.cimadamore at oracle.com
>> <mailto:maurizio.cimadamore at oracle.com>>  wrote:
>>
>>      Hi Ali,
>>      the following looks problematic [the lambda expression is void
>>      compatible, so it should not be possible to convert it to a SAM
>>      descriptor returning String. The rest looks good to me (including
>>      the message that says 'cyclic inference'). We are discussing as to
>>      whether, in cases of cyclic inference, inference variables should
>>      be instantiated eagerly or not (i.e. to Object) so that method
>>      applicability check can continue. For now, the compiler is
>>      conservative, and does not attempt to attribute a lambda body
>>      until the type of the lambda parameters are fully known/inferred.
>>
>>      Maurizio
>>
>>
>>      On 25/05/11 08:21, Ali Ebrahimi wrote:
>>
>>          call(#{ x ->   System.out.println(x);});    /* compile :
>>          reference to call is ambiguous, both method call(SAM1) in
>>          AMBTest and
>>          method call(SAM2) in AMBTest match
>>
>>
>>
>



More information about the lambda-dev mailing list