hg: lambda/lambda/langtools: 8016177: structural most specific and stuckness; ...

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Fri Aug 9 02:50:51 PDT 2013


Hi Ali,
this is not meant to be an improvement at least not one in terms of 
expressiveness. There was an EG discussion last week where we went 
through the overload resolution rules and there was a general feeling 
that rules where too magic/complex (to be honest, this is not the first 
time this comes up). This patch brings some simplification that are 
mostly aimed at making the overload resolution model more uniform and 
tractable.

Now, on the point that this patch goes towards removing implicit lambdas 
- I think that's an unfair argument. All previously written lambda code 
and all the test we had is still compiling without a glitch (despite 
implicit lambdas are used almost everywhere). There were layers of 
complexity in the compiler that simply weren't needed anymore as a 
result of changes in the libraries that occurred in the last few months 
- so I think it's a good thing that we brought the language more in 
synch with the library expectations.

The argument implicit lambdas -> ambiguities is also misleading; you can 
use an implicit lambda whenever the target type of that lambda is 'clear 
enough' from the context. If you have several method declarations each 
one accepting a SAM with different arities, that's enough to rule out 
invalid candidates. But if all candidates agree on the functional 
descriptor arity, I think it's actually a good thing to provide 
client-site disambiguation (i.e. adding an explicit lambda parameter). 
It's better for readability. It's also better because it sidesteps 
important issues in the core model of overload resolution (such as 
combinatorial explosions of type-checking).

Those were essentially the arguments that made all of us decide for a 
simpler model. I believe some writeup of the implemented approach will 
appear soon on the lambda-spec mailing list.

Thanks
Maurizio

On 09/08/13 00:29, Ali Ebrahimi wrote:
> Hi, I don't see this as an improvement. We goes towards removing 
> implicit lambdas. since we have limited its application.So now 
> implicit lambdas just give us ambiguity errors.
> Better would be we have clean and solid solution not remove face of 
> problem.
>
>
> On Thu, Aug 8, 2013 at 6:01 PM, <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>     Changeset: 91c60b02c849
>     Author:    mcimadamore
>     Date:      2013-08-08 14:30 +0100
>     URL:
>     http://hg.openjdk.java.net/lambda/lambda/langtools/rev/91c60b02c849
>
>     8016177: structural most specific and stuckness
>     8016178: Order of unsticking functional expressions
>
>     Simplified interaction between stuck expressions and overload
>     resolution. Now implicit lambdas are considered as stuck and
>     cannot be used to disambiguate between multiple applicable methods
>     (same holds for overloaded method reference). In such cases,
>     disambiguation is only provided by the provisional applicability
>     arity-based check. Added new warning (-Xlint:overloads) to flag
>     potentially ambiguous declarations.
>
>     ! src/share/classes/com/sun/tools/javac/code/Flags.java
>     ! src/share/classes/com/sun/tools/javac/code/Lint.java
>     ! src/share/classes/com/sun/tools/javac/code/Types.java
>     ! src/share/classes/com/sun/tools/javac/comp/Attr.java
>     ! src/share/classes/com/sun/tools/javac/comp/Check.java
>     ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
>     ! src/share/classes/com/sun/tools/javac/comp/Infer.java
>     ! src/share/classes/com/sun/tools/javac/comp/Resolve.java
>     ! src/share/classes/com/sun/tools/javac/resources/compiler.properties
>     - test/tools/javac/Diagnostics/compressed/T8012003c.java
>     - test/tools/javac/Diagnostics/compressed/T8012003c.out
>     - test/tools/javac/diags/examples/BadArgTypesInLambda.java
>     + test/tools/javac/diags/examples/PotentiallyAmbiguousOverload.java
>     ! test/tools/javac/lambda/8016177/T8016177a.java
>     ! test/tools/javac/lambda/8016177/T8016177a.out
>     ! test/tools/javac/lambda/8016177/T8016177c.java
>     ! test/tools/javac/lambda/8016177/T8016177c.out
>     ! test/tools/javac/lambda/8019480/T8019480.out
>     ! test/tools/javac/lambda/BadRecovery.out
>     ! test/tools/javac/lambda/ErroneousLambdaExpr.java
>     + test/tools/javac/lambda/ErroneousLambdaExpr.out
>     ! test/tools/javac/lambda/MethodReference22.out
>     ! test/tools/javac/lambda/MethodReference23.out
>     ! test/tools/javac/lambda/MethodReference41.java
>     + test/tools/javac/lambda/MethodReference41.out
>     ! test/tools/javac/lambda/MethodReference42.java
>     + test/tools/javac/lambda/MethodReference42.out
>     ! test/tools/javac/lambda/MethodReference43.java
>     + test/tools/javac/lambda/MethodReference43.out
>     ! test/tools/javac/lambda/MethodReference44.java
>     + test/tools/javac/lambda/MethodReference44.out
>     ! test/tools/javac/lambda/MethodReference46.java
>     + test/tools/javac/lambda/MethodReference46.out
>     ! test/tools/javac/lambda/MethodReference47.java
>     ! test/tools/javac/lambda/MethodReference47.out
>     ! test/tools/javac/lambda/MethodReference48.java
>     + test/tools/javac/lambda/MethodReference48.out
>     ! test/tools/javac/lambda/MethodReference70.out
>     ! test/tools/javac/lambda/MethodReference71.out
>     ! test/tools/javac/lambda/MostSpecific04.java
>     + test/tools/javac/lambda/MostSpecific04.out
>     ! test/tools/javac/lambda/MostSpecific05.java
>     + test/tools/javac/lambda/MostSpecific05.out
>     ! test/tools/javac/lambda/MostSpecific08.java
>     + test/tools/javac/lambda/MostSpecific08.out
>     ! test/tools/javac/lambda/TargetType01.java
>     + test/tools/javac/lambda/TargetType01.out
>     ! test/tools/javac/lambda/TargetType02.java
>     + test/tools/javac/lambda/TargetType02.out
>     ! test/tools/javac/lambda/TargetType21.java
>     ! test/tools/javac/lambda/TargetType21.out
>     ! test/tools/javac/lambda/TargetType24.java
>     ! test/tools/javac/lambda/TargetType24.out
>     ! test/tools/javac/lambda/TargetType26.out
>     ! test/tools/javac/lambda/TargetType39.out
>     ! test/tools/javac/lambda/TargetType43.out
>     ! test/tools/javac/lambda/TargetType57.out
>     ! test/tools/javac/lambda/TargetType66.java
>     ! test/tools/javac/lambda/TargetType66.out
>     ! test/tools/javac/lambda/mostSpecific/StructuralMostSpecificTest.java
>     - test/tools/javac/lambda/typeInference/InferenceTest5.java
>     ! test/tools/javac/lambda/typeInference/InferenceTest_neg1_2.out
>
>
>



More information about the lambda-dev mailing list