should haddock.ghc be a sub-repo of ghc?

[Claus Reinke]

ok, it seems the consensus on the subject question is "no"
(fine by me), that ghc api users are on their own with trying
to follow the api (hmm, ok, i guess), but that ghc api users
should help with its design (good idea, though i've long had
my doubts about the "users suggest a good design" part;-).

1 as for haddock.ghc:
    i'm still unhappy with the current distribution scheme:

    - as far as i know, haddock.ghc is only distributed in
        source form, which shouldn't be a problem, but

    - i've got several ghcs on my disk (6.4.1, 6.6.1,
        clean head for validate, patched head for use) -
        and, unless i'm misunderstanding something (?),
        *none of them can be used to build haddock.ghc*!

    - haddock.cabal proclaims no tool dependencies,
        and its 'build-depends:' says: ghc>=6.8

    even if the cabal file was more accurate, i don't
    think this is a workable scheme. my preference
    would be for a darcs repo that works with any
    ghc>=6.8, but versioned source or binary dists
    might work as well

2 as for ghci api design help:
    ghc hq has asked for that for a long time, and as one
    of those who asked for a standard haskell compiler 
    api before ghc api came into being, i sometimes feel
    guilty for not sitting down an trying to come up with
    something. 

    then again, i believe it is too early in the game to try 
    and settle on the ultimate ghc api design, and since 
    the api is so closely linked to ghc's internals, a major 
    overhaul would be somewhere between painful and 
    impractical (a meta suggestion: whenever a change to
    ghc breaks the api, it might be worth considering a
    layer of indirection for that api feature that would have 
    hidden the internal change from the api). so i think 
    we'll have to keep making suggestions for improvements 
    in small steps, raising the topic whereever it comes up 
    (haddock.ghc, ghctags, ghci, ghc, Neil's tools, ..).

    perhaps having a dedicated ghc api list would help
    (at least, people wouldn't jump on posters telling
    them to fix their issues outside of ghc;-), but i'm
    worried that it would go the same way as the
    template haskell list: mostly silent, with occasional
    postings suggesting continuous secret use.

    so, how about a ghc api bugs list instead?-) i'm
    thinking of a list where (a) ghc api users register
    their darcs repos for testing, (b) ghc api users 
    discuss issues they have with the current api or 
    with upgrades, (c) ghc api hackers announce 
    overhauls and raise design plans as they emerge.

    (c) would be better than just seeing code fail
    after random updates - one would see motivation
    and intended workarounds, might even discuss
    issues ahead of implementation. (b) seems to be
    the only area in which the template haskell list
    does create traffic. (a) would allow exchange of
    ideas, as well as surveys of api usage patterns,
    and ghc hq might maintain a list of those repos, 
    and run a buildbot over them after nontrivial api 
    changes, for their own peace of mind (or not?-).

claus