Reference implementation

[Neal Gafter]

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.

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> 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>> 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>>
>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>