Playing with new compiler

[Maurizio Cimadamore]

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.
>
My bad, I missed the last line in your email. This is another problem in 
your original example (so there seem to be 2 of them).

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
>>
>>
>>
>