Isaac Jones
1. Hat requires users to restrict themselves to a certain small subset of the standard libraries, and to use hmake
Also the issue of how libraries are distributed in Haskell is a little bit in flux at the moment, since Cabal is still being polished.
This doesn't really have anything to do with Cabal as far as I know. Hat comes with pre-translated libraries for a subset of the GHC libraries. It's true that the libraries that come with the compilers may change in the future, partly due to Cabal, but I don't think this is the reason that Hat doesn't come with all the libraries. Hat doesn't even use Cabal, AFAIK, but hmake.
Well, the hope is that, eventually, Hat should be able to take any Cabal-ised library and transparently build it for tracing. Or maybe it will be Cabal that will support building for tracing as one "way" amongst others (profiling, etc). In any case, the point is that Hat pre-dates Cabal and so has no support for it, that Cabal is still under development, and that eventually there should be a good story for using Cabal+Hat together, but it isn't there right now.
2. Buddha doesn't work with GHC 6.4
True. This is a cabal issue, that I haven't had time to resolve. buddha is limited to even fewer libraries than Hat.
Why is this a Cabal issue? Are you interested in adding Buddah support to Cabal?
I think what Bernie is referring to is that ghc-pkg-6.4 uses an input file format very similar to Cabal's file format, for registering a new package. I would guess that Buddha needs to register a "buddha" package with ghc, but for now doesn't have the right syntax. The file formats of Cabal and ghc-pkg are so similar that many people think they are the same thing, hence he can be forgiven for referring to it as a Cabal issue, rather than a ghc-pkg issue. Regards, Malcolm