Jhc does not need to do anything to support cabal, cabal is what would need to support jhc. jhc already exports all the functionality needed for cabal to interface with it if wanted. That said, it wouldn't help a lot. Cabal is pretty poorly designed, it has trouble keeping up with compatibility between different versions of ghc, let alone different compilers. All of the cabal dependecies are in terms of specific version numbers of ghc libraries (!!) rather than actual feature tests meaning unless you had a database of ghc -> jhc mappings that was continually maintained, or convinced every person to continually test against every compiler, things won't work. I moved to YAML because trying to parse cabal files was always just a hack, it wasn't real support for cabal files because that can't easily be done, it just confused things to try so didn't and went with a standard format at the same time. John On Sat, Mar 16, 2013 at 11:34 AM, Kiwamu Okabe <kiwamu@debian.or.jp> wrote:
Hi Brandon.
On Sun, Mar 17, 2013 at 3:11 AM, Brandon Allbery <allbery.b@gmail.com> wrote:
Arguably its the other way around, as you found in the Cabal source: jhc can use whatever it wants, while it would be nice if Cabal (and hence cabal-install) supported jhc.
Whether jhc uses Cabal internally is not relevant to whether cabal supports jhc: for example, cabal supports Hugs, which does not itself support (and can't support, given how it works) cabal.
I don't understand Cabal completely. Cabal library is compiled by jhc or GHC? And jhc does not have database such as ghc-pkg. Is it easy to support Cabal without upstream developing power?
Now we have yaml format. And jhc use it. It's true.
Best regards, -- Kiwamu Okabe
_______________________________________________ jhc mailing list jhc@haskell.org http://www.haskell.org/mailman/listinfo/jhc