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? > > Cheers, > Daniel.Sun > > > > -- > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html >
