Reference implementation

[Maurizio Cimadamore]

Neal Gafter wrote:
> Maurizio-
>
> Here's my concern: Quoting from 
> http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002165.html, 
> inference proceeds in two steps, in this order:
>
>    1. inference from actual vs. formal arguments (see JLS 15.12.2.7)
>    2. inference from return type vs. expected type (see JLS 15.12.2.8)
>
> For consistency, any future extension of inference to argument 
> contexts should also proceed in this order - in fact, must proceed in 
> this order because overload resolution depends on the results of the 
> first step, and the results of overload resolution are required to 
> apply the second step.
Hi Neal
When you say that overload resolution depends on the result of the first 
step, I guess you refer to the fact that both 15.12.2.2, 15.12.2.3 and 
15.12.2.4 refer to 15.12.2.7. Well this is not much of a concern - that 
inference step can be replaced by a full-inference step (round 1 
followed by round 2) where the expected type is unspecified.

Moreover, we think that it is very important to be able to refactor code 
like:

class Foo<X> {
    Foo(X x) {...}
}

Foo<Object> fo = new Foo<Object>(1);

with your proposed approach the above code will give an error (see 
statistics and results in [1]). If you can think of an extension to your 
approach so that the above code will be accepted when refactored with 
diamond I'd be more than happy to discuss in more details.

Maurizio

[1] - 
http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002159.html
>
> To extend the diamond operator to argument contexts, the diamond 
> operator would have to be changed to proceed in these two phases.  The 
> prototype's currently implemented "simple inference" only applies the 
> second of these steps.  My concern is that such a future change 
> (inserting a new first phase) to the diamond operator would be 
> incompatible.  If that proves true, including the current approach 
> into jdk7 would foreclose a possible future extension of type 
> inference to argument contexts.
>
> So, if we want to keep our options open to support inference in 
> argument contexts in the future, we should either (1) Demonstrate that 
> a change from the currently implemented approach to a two-phase 
> approach is not a breaking change, or (2) Use a two-phase approach now.
>
> Cheers,
> Neal
>
> On Wed, Oct 28, 2009 at 2:26 AM, Maurizio Cimadamore 
> <Maurizio.Cimadamore at sun.com <mailto:Maurizio.Cimadamore at sun.com>> wrote:
>
>     Hi Neal
>
>
>     Neal Gafter wrote:
>
>         I see.  Based on that, it appears that the "full-complex"
>         approach can't be generalized to argument contexts (because
>         inference results would be required for overload resolution,
>         but overload resolution results would be required for
>         inference).  
>
>     Could you please formulate a bit more about the above point? I
>     don't think that "full-complex" cannot be generalized - but of
>     course it means that overload resolution should be extended in
>     order to handle method arguments that have a ForAll type (to speak
>     the javac lingo). This extension would be required anyway if
>     inference is to be extended in order to support more call sites
>     (e.g. argument position). In other words I don't see in the
>     full-complex approach more problems than in expanding the scope of
>     ordinary javac type-inference - and, if the implications of the
>     latter are not so promising, then I'm not so sure about what you
>     refer to when you speak of language evolution in this area.
>
>     Maurizio
>
>
>         Therefore if we want to support inference in argument contexts
>         in the future, the choice is between "simple" and "complex".
>          Given that they are incompatible, and only the "complex"
>         approach generalizes to argument contexts, we seem to have
>         integrated the wrong approach into the code base.
>
>         So, taking the future evolution of the language into
>         consideration, what plans are there to revise the prototype?
>
>         Cheers,
>         Neal
>
>         On Tue, Oct 27, 2009 at 5:16 PM, Jonathan Gibbons
>         <Jonathan.Gibbons at sun.com <mailto:Jonathan.Gibbons at sun.com>
>         <mailto:Jonathan.Gibbons at sun.com
>         <mailto:Jonathan.Gibbons at sun.com>>> wrote:
>
>            Neal,
>
>            Maurizio defined these terms in emails to coin-dev round
>         about Aug 22.
>
>            "simple" and "complex" are defined here:
>          
>          http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002159.html
>
>            I believe "full-complex" first appeared here:
>          
>          http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002165.html
>
>            I'll leave Maurizio to provide any updates on the terminology.
>
>            -- Jon
>
>
>
>
>            Neal Gafter wrote:
>
>                Maurizio:
>
>                Can you please define the "complex", "simple", and
>             "full-complex"
>                approaches?  Which is used in the current
>             implementation?  Which approach
>                can support inference in argument contexts (i.e. part
>             occurs before overload
>                resolution, part after)?
>
>                Cheers,
>                Neal
>
>                On Mon, Oct 26, 2009 at 10:04 AM, Maurizio Cimadamore <
>                Maurizio.Cimadamore at sun.com
>             <mailto:Maurizio.Cimadamore at sun.com>
>             <mailto:Maurizio.Cimadamore at sun.com
>             <mailto:Maurizio.Cimadamore at sun.com>>> wrote:
>
>                  
>
>                    Paul Benedict wrote:
>                        
>
>                        Neal,
>
>                        Thank you for raising this point again!
>
>                        It was admitted the current diamond operator
>                     implementation is
>                        incomplete compared to the "complex/full"
>                     solution. It was also
>                        admitted the partial solution is not a "true
>                     subset" of the "complex"
>                        solution. With that said, I am concerned the
>                     partial solution will
>                        infer somethings in JDK 7, but a later JDK
>                     using the "complex"
>                        solution would infer differently or invalidate
>                     inferences of the
>                        partial solution. Joe, is that possible?
>
>                              
>
>                    Both complex and simple are subset of full-complex.
>                 If some future
>                    release will switch to full-complex the transition
>                 will be smooth (no
>                    strange mismatch in types inferred by the diamond
>                 algotithm). On the
>                    other hand switching from simple to complex and
>                 vice-versa will cause
>                    problems.
>
>                    Maurizio
>                        
>
>                        Paul
>
>
>                              
>
>                        
>
>                  
>
>
>
>
>