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
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
