Reference implementation

[Maurizio Cimadamore]

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