JSR 335 Lambda Specification, 0.6.0

[Remi Forax]

On 12/08/2012 05:42 AM, Dan Smith wrote:
> Attached is the 0.6.0 revision of the Lambda spec.  I'm collecting feedback for a week or two, and then will push a revision out for public review.

section 3.9:
I still don't see why we introduce a new keyword ('_') that will break 
compatibility for not using it.
We can do that later if we want (or never).

section 18.2.1:
"If the expression is a class instance creation expression or a method 
invocation,
and its type when treated as a standalone expression is /S/, the result 
is /S →_c T/."

There is nothing in the discussion that say why
1) it should not be an error instead of using Object as type argument 
(compatibility maybe ??)
2) why the inference can not be propagated and wait for the result of 
the poly expression.

In section 18.2.1.2, in the discussion, the item 4, I don't understand 
why it doesn't work.
javac agree with me :)

interface Sequence<E> {
<M> M mapReduce(M base, Function<E, M> mapper, BinaryOperator<M> op);
}
interface Person {
public String name();
}
public static void main(String[] args) {
Sequence<Person> ss = null;
String names = ss.mapReduce("", p -> p.name(), (s1, s2) -> s1+", "+s2); 
// ok
}

E is person because ss is a Sequence of Person, M is a String because 
base="", so where is the issue ??

Section 18.2.1.3
I'm lost here. Why do you erase the type of the method reference 
considering it as a lambda without parameter types ??

Section 18.2.5
I agree that checked exception should not be part of the applicability 
of a method.


Section 18.5.1 and section 18.5.2,

I think you should add a shortcut in the applicability rules.
If there is only one method with the correct name and number of 
parameters, the inference should use the target type.
Or said differently, if finding the applicable method fail because a 
type argument is not found, the compiler should try again inserting the 
fact that the target type is known,
and if only one method is applicable, it's the most specific method.

so it will not solve this case like this that we rule out during the 
face to face meeting:
Future<?> future = executor.submit(() -> list.add("foo")); // a Callable 
or a Runnable
but solve
ArrayList<String> list = stream.into(new ArrayList<>());

>
> —Dan

Rémi

>
> -----
>
> Change notes:
>
> Overall: Split Part F into Part F, Overload Resolution and Part G, Type Inference. Split the old Part G into Part H, Default Methods and Part J, Java Virtual Machine.
>
> Functional Interfaces: Defined intersections as a kind of functional interface type. Defined the descriptor of wildcard-parameterized types. Added the annotation.
>
> Lambda Expressions: Added the _ keyword and the -> operator to the grammar.
>
> Method References: Added qualified super references. Added array constructor references. Added the :: separator to the grammar.
>
> Poly Expressions: Allowed casts to intersection types. Refined the conditions under which a method invocation is considered a poly expression. Introduced rules for classifying and typing conditional expressions.
>
> Typing and Evaluation: Refined the presentation of inference of wildcard-parameterized type instantiations. Allowed arbitrary statement expressions in lambda bodies targeting a void return. Always interpret lambda returns in an assignment context. Defined runtime behavior when targeting an intersection functional interface type. Eliminated support for unbound inner class constructor references. Added support for qualified super references and array constructor references. Restricted supported forms of static method references.
>
> Overload Resolution: Defined potentially applicable for methods with functional interface parameter types targeted by lambda expressions. Revised most specific method analysis to consider the invocation argument expressions, compare descriptors of functional interface types, and minimize boxing/unboxing.
>
> Type Inference: Added a stub for most specific method inference.
>
> Default Methods: Modified syntax, treating default as a method modifier. Added support for static interface methods. Refined the inheritance rules for default and abstract methods. Enclosing instances of inner classes can be interfaces. Added support for the package access modifier.
>
> -----
>
> Major things left until the next spec iteration:
> - Spec for inference enhancements
> - Refine JVM resolution rules; specify 'invokespecial' and 'invokestatic'
> - Spec for JVM bridge methods
>
> -----
>