Part G - Concerns.

[Maurizio Cimadamore]

Good luck with F & G ;-)

To address your concern, I know that a new draft with all inference 
sections is in the works and will be made available. The goal of the 
current draft is to define the high-level framework in which inference 
operates.

In terms of the implementation, I believe the current status of the 
inference engine in javac [1] captures the design fairly closely, and it 
can be used as a valid starting point.

[1] - 
http://hg.openjdk.java.net/jdk8/jdk8/langtools/file/tip/src/share/classes/com/sun/tools/javac/comp/Infer.java

Maurizio

On 20/02/13 07:01, Srikanth S Adayapalam wrote:
> Good morning,
>
>          With the eclipse compiler implementation [excluding code
> generation] of
> Parts A-E essentially complete and part H nearly so, we are working on
> parts
> F & G. The intrepid gladiators who have (despite not being armed with a
> double
> PhD in Math and Comp.Sc :)) chosen to enter the colosseum to tame these
> two lions
> are respectively, yours truly (F) and Stephan Herrmann (G).
>
> Please find below a high level assessment from Stephan, the Eclipse JDT
> implementation
> lead for the 335 type inference project on the state of the specification
> of Part-G.
> I have requested Stephan to raise (where the state of part G would permit)
> specific
> point issues with example code to ask pointed questions about specified
> behavior or
> to call out lack of clarity and we will try and do that in the coming days
> and weeks.
> I am also studying this part in detail to formulate my own opinion, but
> given the
> gravity of his assessment, I wanted to share it as is already.
>
> Thanks!
> Srikanth.
>
> ----------------------------------------
> I appreciate the effort to put the specification of type inference
> on more solid grounds, as this should help to reduce the deviations
> between different compilers which all adhere to the same specification.
> However, as of the 0.6.1 early draft of JSR 335 the section "18 Type
> Inference" is not in a state that can be used for any downstream
> activities. It is not possible to implement a type checker based on
> this draft nor is it possible to validate whether the given rules
> actually produce the desired results.
> The main problem is that sections 18.3 and 18.4 are completely missing
> (except for "To do" place holders). These sections should contribute
> to the back bone of the algorithm of type inference and without these
> not a single example program can be type checked.
> Many more sections contain similar "To do" placeholders, 18.2.3 ff.
> might be critical, too, whereas some others may be regarded as details
> that can be filled in last minute.
> As an example consider the fact that the algorithm terminates when
> inference variables are "resolved" as represented by an equality type
> constraint. However, not a single rule in the specification will ever
> *create* such a constraint.
> IMHO, the specification needs a significant period of validation between
> the day when it is considered complete and the point where agreement
> can be achieved that this will indeed be the foundation of Java 8 as
> a standard. Looking at the milestone schedule for Java 8 I am very
> worried that JSR 335 will ship an underspecified type system that puts
> users at the mercy of the intuition of compiler engineers.
>
> Stephan.
> -------------