hg: lambda/lambda/langtools: Next round of implementation reflecting the latest 'State of the Lambda' draft; implemented features are:

[Neal Gafter]

On Fri, Jul 23, 2010 at 12:12 PM, maurizio cimadamore <
maurizio.cimadamore at oracle.com> wrote:

>  On 23/07/2010 19:46, Neal Gafter wrote:
>
> On Fri, Jul 23, 2010 at 11:17 AM, maurizio cimadamore <
> maurizio.cimadamore at oracle.com> wrote:
>
>>  I cannot tell from the specification nor from the test cases provided.
>> Is the invocation of toString() qualified (by an anonymous subtype of S1) in
>> the generated bytecode as required by the JLS?  The comment in TargetType01
>> is mysterious ("ambiguity here - the compiler does not try all the
>> combinations!"): this code would be ambiguous whether or not the compiler is
>> required to "try all combinations".
>>
>>   You are right, +(String,String) would still be a valid expression; I
>> will update the test so that one candidate is Func<Integer, Integer> and the
>> other one is Func<DontUseMeInABinaryExpression,
>> DontUseMeInABinaryExpression> ;-)
>>
>
> Sounds good.  Then the obvious question is: by what language rule would the
> invocation be ambiguous?
>
> so, you have two methods M1 and M2. Both are applicable given a set of
> actual argument types A1, A2 ... An, by method invocation conversion.
> Unfortunately neither M1 is more specific than M2, nor M2 is more sepcific
> than M1.
>

Except in this case the "actual argument types" may be lambda expressions,
the return type and thrown exceptions of which are necessary for determining
if the method is applicable or not.  But those can only be computed by
performing semantic analysis on the lambda body, which is what you said you
weren't going to do.  So how *are* you going to determine which methods are
applicable?