This darcs2 style of announcements seems to be infective. Your
message sounds as if you'd like someone to tell you that no, you
shouldn't really merge?-)
1. Going directly from not-even-in-head to in-release-candidate
sounds scary, especially if it is going to be the only alternative,
with no compatibility fallback, right at the core of ghc.
2. Have you converted, bootstrapped and tested the core ghc api
clients (ghc, ghci, haddock), do they still build and pass all their
tests? Without this, merging your code would prevent a release.
With this, you should have some data wrt difficulty, confidence,
and benefits.
3. If you're going to break all ghc api clients, at least your self
should be convinced that we're getting something very good
out of it - my understanding from early versions of your code
was that you're:
a splitting compiler phases
b making implicit session monads explicit
c cleaning up and unifying error handling
d trying out some changes enabled by a-c
a-c sounded like useful and incremental improvements, with
only d anything to worry about. Now you're saying that a-d
are so intertwined that the whole is neither incremental nor
are you yourself convinced it is all that useful?
4. "we can throw in more breaking changes, to make the mess
bigger" - you're not seriously suggesting this as a "pro" argument?-)
So, since you asked for it: no, you shouldn't merge your code -
things would go wrong horribly, and nothing can be worth that!-)
Now, your task is (a) to convince everyone that things wouldn't
go wrong (at least 2 above), (b) that there are clear advantages
of doing everything your way (backed up with data from 2), and
(c) there are (temporary) fallback options for those who do not
want to adapt to your changes immediately.
Is this what you wanted to hear?-)
Claus
--
Stop pushing that envelope. The mac will break.
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
