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

Neal Gafter neal at gafter.com
Fri Jul 23 11:46:11 PDT 2010


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?

>   However, it isn't clear from the specification or the test cases what
> would happen in cases where this comment would be meaningful.
>
> The short story is that the compiler uses all the info it can in order to
> reduce the list of potential candidates in an overloaded method call. Such
> info might include particlly attributed parameter types, inferred (from
> lambda body) thrown/return type, type-parameter bounds (in the candidate
> method), etc. If the list of candidates does not have a maximally specific
> method, then an ambiguity error is issued, as usual. The compiler however
> *does not* perform a trial-and-error attribution process in order to further
> reduce candidates from the list (e.g. reasoning of the kind: if this target
> type applied to the lambda body causes attribution errors, then remove the
> candidate from the list).
>

That's a confusing description.  On the one hand, you say that the compiler
uses all information available.  On the other, you say what techniques the
compiler does not use.  It isn't clear how to write a compile to "use all
the info it can" while avoiding trial-and-error.  I can imagine increasingly
complex schemes that disambiguate particular use cases without
trial-and-error, but it would be better to have, once and for all, and clear
specification of what precisely the language is and is not.  Then the
compiler will use whatever techniques are required to implement that
specification.


More information about the lambda-dev mailing list