Part G - Concerns.

[Srikanth S Adayapalam]

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