In my experience it's rarely possible to have a starr as a separate commit.
I'd also like to mention the question of quasiquotes. Prohibiting scalac from being built with transient starrs means that we will significantly slow down adoption of quasiquotes in our codebase.
Yes, Lukas' example is a very nice illustration for the problem at hand. I think his proposed solution is quite good here. I think though it's not a problem that we need some hacking around to handle this situation. The hack still can be made in a separate commit and documented, which is both sufficient and scalable.
I also have to retract my assessment about rarely having a possibility to have a starr as a separate commit. I used to work in an area of the compiler that was in constant flux and that touched a lot of stuff (e.g. classtag refactorings). In that area it was indeed very frequent to have to bend over backwards to perform changes. However nowadays I very infrequently find myself in need of doing non-trivial things wrt starr. It's almost always "change something, commit, rebuild a starr, commit, clean up old stuff, commit".
Quasiquotes are the ultimate way to work with trees. The readability difference between manual construction (and deconstruction) and quasiquotes is humongous.The quest of improving the quality of our codebase has been very difficult. Even tiny improvements have been achieved with significant effort. Quasiquotes offer something really big in this area, therefore I think it's useful to think twice about being overly conservative.
Well, we're discussing potential implications of the proposed change,
and quasiquotes outline such implications. I don't think we should
drop this line of conversation just because it's about a yet
1-2 months of delay is only one facet. Another one is discovering and
fixing bugs in quasiquotes while migrating the compiler to using them.
Every such bug will impose more delays.
By the way could we also please explicitly hear the benefits of the
And one more thing. What are the new defaults for PR validation? Is
this something that's being proposed, or it's already been implemented
Well, current starr mechanism look pretty stable to me. After the linked discussion I rethought my approach which was indeed not very careful, and everything was fine and reproducible ever since.What do you mean by "correctly built"?
If the risk of having fatal problem like that is high then quasiquotes shouldn't be introduced until the risk is lowered because they may hamper productivity of all the people working on the compiler that might not be interested in debugging issues related to quasiquotes. If the risk is low (we have reasonable confidence that quasiquotes are stable enough) then the delay of 1-2 months for delivering bug fixes shouldn't be a problem IMO.In case of a real need, we could publish a tagged release between milestones. But that should be the exception rather than the rule.
Wait a second. What are the benefits over the current approach? Why migrate from the old mechanism in the first place?
1) How is this different from the current system? Starrs also provide a way to standardize a compiler version, right?
2a) Did we have a lot of occasions in the past when new starrs caused regressions? How significant is that number in comparison with the number of other regressions?
2b) Quasiquotes are just a library, modulo a small pattern matcher hack. How is using quasiquotes different from introducing something new in a standard library and using that something in stdlib or in the compiler itself?
3) From the looks of it, we can retain our current system and skip building locker.
It still seems unlikely you could have a compiler that passes the stability test but fails the test suite when bootstrapped.
If the compiler is unstable, you'll get runtime issues popping up. I'm with lukas, but I also think having unstable bytecode may cause erroneous failures too.
I.e. using the new compiler that is unable to generate byte code that links to itself at runtime.
simply swapping out the existing Scala compiler for one
that has better internals does not advance all that many goals.
On Monday, June 24, 2013 10:00:28 AM UTC-4, lexspoon wrote:simply swapping out the existing Scala compiler for one
that has better internals does not advance all that many goals.If the existing compiler was already satisfactory, then I'd agree.But it isn't satisfactory. "Slow and buggy" — that's Rod Johnson's description of the Scala compiler in his Scala Days keynote. (And he's not just some grouchy compiler hacker...)
Slowness and bugginess are systemic issues. They can't be fixed by tweaking and patching. "Better internals" are exactly what's needed in order to address them.Case in point: the new pattern matcher in Scala 2.10. Pervasive quality issues, slain — by better internals.
I disagree with the "buggy" bit. I think 10% of the users/features encounter/cause 90% of the bugs.
I think it's also a counter-argument: it cost us nearly a person year. We don't have that kind of resources for every bit of the compiler that needs replacing.There's a huge risk in replacing the internals wholesale beyond just the cost -- how do you know they'll be better?