From daniel.smith at oracle.com  Sun Sep  1 15:21:01 2013
From: daniel.smith at oracle.com (Dan Smith)
Date: Sun, 1 Sep 2013 16:21:01 -0600
Subject: Overload resolution simplification
In-Reply-To: <5221CF92.5020100@univ-mlv.fr>
References: <71B94777-2E9D-4F9A-A7E4-86294BC5F107@oracle.com>
	<D95CACE3-9308-4476-A0D3-6E07BEBFB0D1@oracle.com>
	<5221CF92.5020100@univ-mlv.fr>
Message-ID: <0D1DD277-06B7-4C61-A36A-BAFE7695475D@oracle.com>

On Aug 31, 2013, at 5:12 AM, Remi Forax <forax at univ-mlv.fr> wrote:

> I disagree that the actual overload resolution is independent on the context,
> the choice of the most specific method is but the choice of applicable methods is not independent of the context.

Sorry, I'm not following.  How is applicability dependent on the context in which the invocation appears?  Can you illustrate?

> so when there are several overloads and an implicitly typed lambda,
> we can first try to select a subset of all overloads (like we currently select applicable methods) and then
> use the fact that the inferred signature must be the same for all applicable overloads.

Again, not following.  What is the basis for selecting "a subset of all overloads"?  If we know the inferred parameter types must be the same, even if we don't know what they are (which is always true for comparing, I think you're saying), how do we "use [that] fact"?

?Dan


From forax at univ-mlv.fr  Sun Sep  8 09:18:26 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 08 Sep 2013 18:18:26 +0200
Subject: No 'fold left' without a combiner ?
In-Reply-To: <522B7539.30501@oracle.com>
References: <51E40C99.30406@univ-mlv.fr>
	<CACzrW9BP7_Gaxjt=Fi2cYf8NtPNSSa4eyLLEMivWveX2qh-voQ@mail.gmail.com>
	<CAL2Kp+jvqTGu7UOG=0tWPELmB9Li4i6hfsF3ST0hc88RL7qxGg@mail.gmail.com>
	<CACuKZqF2L4_RHQNL0HL0_DfySZgsohFgA3nbqnMAoBB9V5ceJA@mail.gmail.com>
	<9FC2B838-26C5-47DB-A24F-2EE6F8520F56@oracle.com>
	<CACuKZqGvoL10JTuXyYWL4mgOzZy9QShfiD7rweZqZsEcxfAeiw@mail.gmail.com>
	<522A58FF.8080401@oracle.com> <522AEC19.7050801@univ-mlv.fr>
	<522B36AF.6070707@oracle.com> <522B4DE4.90805@univ-mlv.fr>
	<522B5EC3.9010105@oracle.com> <522B724B.3030703@univ-mlv.fr>
	<522B7539.30501@oracle.com>
Message-ID: <522CA352.60501@univ-mlv.fr>

Did I say that I will send you an email to the EG lists each time I will 
be annoyed by visibility of lambda parameter rule ?

ArrayList<Advice> advices = ...
AnnotatedElement annotatedElement = ...
MethodHandle mh = advices.stream().reduce(impl, (mh, advice) -> 
advice.chain(annotatedElement, mh), null);

In fact, there is another issue, (the real reason of this email), this 
code throws a NPE at runtime because I use null as combiner.
It seems there is no way to express a left fold on values (different 
from T) when the values can not be combined.

I've fixed the issue by writing,
   MethodHandle target = advices.stream().reduce(impl,
       (mh, advice) -> advice.chain(annotatedElement, mh),
       (_1, _2) -> { throw new AssertionError(); } );
but it's clearly ugly.

cheers,
R?mi


From SPULLARA at YAHOO.COM  Sat Sep 14 14:13:25 2013
From: SPULLARA at YAHOO.COM (Sam Pullara)
Date: Sat, 14 Sep 2013 14:13:25 -0700
Subject: Line numbers for lambdas
Message-ID: <9DC5C790-5272-4DCF-97C7-A992261E1382@YAHOO.COM>

It looks like when you are debugging lambdas, the frame above the lambda is the synthetic method frame and it has a line number of -1. Seems like we should have that be the line where the lambda is defined instead.

Sam


From daniel.smith at oracle.com  Fri Sep 20 16:03:16 2013
From: daniel.smith at oracle.com (Dan Smith)
Date: Fri, 20 Sep 2013 17:03:16 -0600
Subject: JSR 335 Lambda Specification, 0.6.3
Message-ID: <6CA237E7-3610-4098-A873-AAE9B7594F69@oracle.com>

An updated specification can be found here:

http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.3/

Other links
Diff: http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.3-diff.html
One-page HTML: http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.3.html
Downloadable zip: http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.3.zip

This ties up most loose ends, and can be viewed as a preview of the Public Review (planned for next month).  There are likely some rough edges to polish before that time (broken links, unclear wording, etc.).  Parts F, G, and J are much more stable than in the past, documenting final plans for overload resolution, type inference, and VM changes.

Full change log, from the document:

> Functional Interfaces: Renamed the term function descriptor to function type (undoing the previous renaming of functional interface type to function type). Cleaned up the conditions under which an intersection type can be considered a functional interface type. Addressed a negative interaction of wildcards with derivation of a function type.
> 
> Lambda Expressions: Introduced the terms explicitly-typed lambda and implicitly-typed lambda. Changed treatment of "_" to allow it as a name in non-lambda contexts (noting the possibility of future deprecation).
> 
> Typing and Evaluation: Introduced the terms exact method reference and inexact method reference. Removed the compatibility condition for lambda expressions that their body not contain errors. Introduced a section detailing the process of identifying a compile-time declaration for a method reference (distinct from testing for compatibility). Adjusted resolution of an unbound/static method reference to be less brittle.
> 
> Overload Resolution: Asserted that arguments involving implicitly-typed lambdas and inexact method references are not pertinent to applicability; they are only checked for arity during overload resolution. (This replaces the approach of considering some methods to be only provisionally applicable.) Minimized the changes to most-specific analysis, so that extra (non-subtyping) work is only done when two functional interfaces are compared and correspond to an explicitly-typed lambda or an exact method reference. Adjusted potential applicability of an unbound/static method reference to be less brittle. Made the accessibility of a varargs type a post-resolution check.
> 
> Type Inference: Added new bounds to represent capture variables and variables that appear in throws clauses, and described their impact on incorporation and resolution. Eliminated the notion of "delayed constraints". Defined special reduction rules for exact method references. Described reduction of throws constraints. Described how invocation type inference handles sequencing of reduction for constraints on arguments that are not pertinent to applicability, as well as throws constraints (interleaved with resolution of variables, as needed). Made use of capture bounds during invocation type inference.
> 
> Default Methods: Prohibited static and default methods from the body of annotation type declarations (@interfaces).
> 
> Java Virtual Machine: Introduced the term maximally-specific superinterface methods for use in resolution and selection. Adjusted resolution to be more flexible and to ignore static andprivate methods in superinterfaces. Prohibited invokespecial from referring to indirect superinterfaces. Cleaned up the selection logic of invokespecial. Clarified how the changes affect older class files. Adjusted definition of overriding to be consistent with actual behavior in VMs.

?Dan