GHC API Refactorings - To Merge or not to Merge?

[Claus Reinke]

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.