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

[maurizio cimadamore]

On 23/07/2010 20:34, Neal Gafter wrote:
> On Fri, Jul 23, 2010 at 12:12 PM, maurizio cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto: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
>>     <mailto: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?
>
As I said in my earlier mail, the compiler uses (among the other things) 
the return type/thrown types inferred from the body of the lambda 
expression. As you can imagine the actual scheme is quite complex as 
there are cases in which such types might depend on the type of 'this' 
which is not available during overload resolution.

Maurizio