[Question] Should jhc support Cabal? Or should use only yaml?
Hi John. Should jhc support Cabal? Or should use only yaml? Some Haskell packages are needed poring to jhc/Ajhc for my usage. I think jhc support yaml format to compile Haskell libraries. But Cabal source code has signs that tried to support jhc. $ git clone git://github.com/haskell/cabal.git $ cd cabal $ git grep -i jhc | wc -l 69 Is it good idea that support Cabal with jhc/Ajhc? Should jhc use only yaml? I would like to follow upstream's concept. Best regards, -- Kiwamu Okabe
On Sat, Mar 16, 2013 at 2:04 PM, Kiwamu Okabe
Should jhc support Cabal? Or should use only yaml?
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. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
Hi Brandon.
On Sun, Mar 17, 2013 at 3:11 AM, Brandon Allbery
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 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
Hi Brandon.
On Sun, Mar 17, 2013 at 3:11 AM, Brandon Allbery
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
Hi all.
On Sun, Mar 17, 2013 at 7:34 AM, John Meacham
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.
Okay. I understand the background jhc and Cabal. By the way, which style fits jhc in future? 1. Jhc includes all YAML files supported. (= current jhc's style) 2. Split jhc repo and YAML files repo. And YAML file repo welcomes user's pull request. (on github? or darcs?) 3. Jhc has only YAML files for base packages. New web service provides YAML file. The sources are gotten from Hackage DB. New web service is wrapper for Hackage DB. If we choose 2 or 3 style, I think YAML file format needs have build-depend section. I want to aim at jhc/Ajhc should be. Thank's for your time, -- Kiwamu Okabe
On Sat, Mar 16, 2013 at 11:34 AM, Kiwamu Okabe
Is it easy to support Cabal without upstream developing power?
No. This is my major issue with how cabal is designed. it is very tied to ghc and a 'closed-world' viewpoint where everything fits into its way of doing things. I really really want to design something better at some point. perhaps after another jhc release I'll spec something out (that would not be jhc specific). That said, it wouldn't be impossible to create a heuristic utility to try to compile cabal programs under jhc. I wouldn't want it something built into jhc but it could be something distributed with it. John
On Sun, 17 Mar 2013, Kiwamu Okabe wrote:
Should jhc support Cabal? Or should use only yaml?
I have once updated JHC support in Cabal because I did not like to install a lot of packages manually. Cabal-install can install a lot of packages in one go. But actually I had to edit all involved Cabal files. Cabal is designed to work with many compilers but if only GHC cares about working with Cabal then this won't work. One central problem is that the package 'base' shipped with GHC is actually a 'ghc-base' and cannot be easily ported to compilers like JHC. I think the correct solution would be a 'base' package that provides real basic functionality that all Haskell compilers provide. This base package could be implemented using compiler specific packages like ghc-base and jhc-base on different compilers but it should expose the same API on all compilers. With such a 'base' package it would be really simple to compile a Cabal package on either GHC or JHC. I think the real missing feature of GHC and JHC is re-exporting a module from another package. With this feature we could re-export a module from ghc-base or jhc-base as module of 'base'.
Hi Henning and others.
On Mon, Mar 18, 2013 at 2:08 AM, Henning Thielemann
I have once updated JHC support in Cabal because I did not like to install a lot of packages manually. Cabal-install can install a lot of packages in one go. But actually I had to edit all involved Cabal files.
I have thought about Cabal and jhc many time. Then I decide to split the problem to two stage. Stage1. * Ajhc is installed with cabal. (Perhaps, also jhc.) * Ajhc's packages (hl files) is installed with jhc's YAML files. Stage2. * Ajhc's package (hl file) is installed with cabal. Now I am trying to build stage1. But stage2 is not needed for my usage. I will create thin wrapper installer for YAML files. Anyone try to build stage2? Best regards, -- Kiwamu Okabe
participants (4)
-
Brandon Allbery -
Henning Thielemann -
John Meacham -
Kiwamu Okabe