2018-04-08 3:58 GMT+02:00 Daniel Sun <realblue...@hotmail.com>:
> Hi all,
> I have a plan named "Phoenix" to share. As we all know, STC is buggy,
> one of reasons is that STC lacks tests during development.
It's interesting you put test coverage as one reason that the STC is buggy,
but the only reason you mention. As the author of most of the code here,
I'd argue that there are way more STC tests than any other feature in the
language :) Almost 1/3 of the test suite is about STC/static compilation. I
think the reasons it's buggy are not to be found here, but on the
complexity of building a type safe feature on top of an AST that was
primarily designed years ago for a dynamic language. In particular, the
ClassNode infrastructure, and the way it handles generics, was a true
nightmare. Second, type inference is extremely hard. Flow typing is also
something complex to get right, in particular discovering variable capture,
or "effectively final" variables. The last part, bytecode generation, is
very easy in comparison. Eventually, the STC was designed as an AST
visitor, which, unfortunately, doesn't allow to carry much context (the
various visit methods do not take a context argument, which would have
helped a lot).
So I'm all in for a new version, but that's not a simple task. Especially
when people disagree on what types should be inferred where. Look at what
happens with Java and the semantics of "var", or list literals, and lambda
type inference. This is the tricky part, which _always_ introduces bugs.
The Java compiler itself is not bug free...
> So I make a plan
> to let STC mature enough:
> 1) Make the Parrot parser be able to parse pure Java source to Groovy AST;
> 2) Use STC to analyze the AST and generate the bytecode;
> 3) Run the existing tests of some famous Java projects, e.g. Spring,
> Hibernate, Guava, Hadoop, etc. ;
> 4) Check the test result. If all tests pass, our Phoenix plan is completed.
> Another benefit of the plan is that we will have a brand new joint
> compiler, no stub generation is required :-)
> Any thoughts?
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html