Part G - Concerns.

[Brian Goetz]

I salute the intrepid gladiators who have taken on this task, which I 
know is not small.

I am not entirely surprised by Stephan's initial reaction on first 
entering the colosseum.  Were I him, I too would be intimidated by what 
is ahead of me!  My advice: breathe.  There is a lot here, but it was 
not pulled out of a hat this morning.  It may take some time to take it 
all in.  And, we're friendly.  No hungry lions here.

He is correct that there are pieces missing in the Type Inference 
section; that was known (and we welcome questions). and we're working on 
filling them in.  However, I don't think the "OMG this is a disaster" 
response is quite warranted.  Is it finished?  No.  But is it so 
incomplete that there is no place to begin?  Again, no.  In fact, a 
third party -- IntelliJ -- has a prototype that has nearly achieved 
feature parity with javac already.  So clearly it is not the case that 
"there's no place to start" or "it can't be done."

So, concerns have their place, but let's not be paralyzed by them.  I'm 
sure that after Stephan takes a few deep breaths, he'll have some 
concrete questions and concerns, and we look forward to them.

Welcome, Stephan.  We look forward to your participation.




On 2/20/2013 2:01 AM, 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. -------------