Re: Advance notice that I'd like to make Cabal depend on parsec
On Sun, Mar 17, 2013 at 09:57:25AM -0700, Mark Lentczner wrote:
Is it essential, or even sensical, that the serialization format GHC needs for storing package info bear any relation to the human authored form? If not, the split out of the package types could be accomplished in a way where GHC uses simple show/read(P) style serialization for storage of package info, where as cabal-lib would use a lovely parsec parser for humans. I'd like this approach.
I think it would be feasible to stop GHC itself from using the human readable format. The only place I can think of it being used is in the package database, but we could use either Read/Show for that, or just exclusively use the binary format. It would be a little less user-friendly, but maybe worth it to remove the ghc library dependencies on most-of-Cabal, mtl and parsec.
Perhaps the major cause is that because GHC is shipped as a library itself, it exposes all it's package dependencies.
Yes.
In otherwords, users that wanted to incorporate the ghc-lib into their programs would depend, and download, and configure, and build, ghc-lib indpenendant of the GHC binaries
I think this would create more problems than it solves.
Okay, perhaps that is all just fantasy. But, no other programming system operates the way we do. They all fall into one of two camps:
- The dominant implementation is maintained, built, and shipped along with a large collection of "common packages". Examples: Python, Ruby, PHP, Java. - The dominant implementation is shipped as a bare tool, and large common libraries are maintained and shipped independently. Examples: C++ (think g++ and boost), JavaScript (think browsers, and jQuery).
We are in the middle and, I think, experiencing growing pains because of it.
I would say that we are doing the first option, in the form of the HP. It's just that the core gets frozen (i.e., ghc + libs gets released) earlier than the higher level libraries. I don't think that moving (back) to trying to freeze/release everything all at once would be an improvement. You just need to remain strong, and keep saying "no" :-) (you're doing a great job, BTW!) Thanks Ian
On Sun, 17 Mar 2013, Ian Lynagh wrote:
I think it would be feasible to stop GHC itself from using the human readable format. The only place I can think of it being used is in the package database, but we could use either Read/Show for that, or just exclusively use the binary format.
I already needed the human readable format in order to check what information a custom configure file generated.
On Sun, Mar 17, 2013 at 09:04:58PM +0100, Henning Thielemann wrote:
On Sun, 17 Mar 2013, Ian Lynagh wrote:
I think it would be feasible to stop GHC itself from using the human readable format. The only place I can think of it being used is in the package database, but we could use either Read/Show for that, or just exclusively use the binary format.
I already needed the human readable format in order to check what information a custom configure file generated.
You can use "ghc-pkg describe p" for that. I don't think you should ever need the human readable format unless you need to alter the package database by hand. -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/
On Sun, 17 Mar 2013, Ian Lynagh wrote:
On Sun, Mar 17, 2013 at 09:04:58PM +0100, Henning Thielemann wrote:
On Sun, 17 Mar 2013, Ian Lynagh wrote:
I think it would be feasible to stop GHC itself from using the human readable format. The only place I can think of it being used is in the package database, but we could use either Read/Show for that, or just exclusively use the binary format.
I already needed the human readable format in order to check what information a custom configure file generated.
You can use "ghc-pkg describe p" for that.
I don't think you should ever need the human readable format unless you need to alter the package database by hand.
I think I also altered these package descriptions in order to check what the correct content should be.
On Sun, 2013-03-17 at 21:04 +0100, Henning Thielemann wrote:
On Sun, 17 Mar 2013, Ian Lynagh wrote:
I think it would be feasible to stop GHC itself from using the human readable format. The only place I can think of it being used is in the package database, but we could use either Read/Show for that, or just exclusively use the binary format.
I already needed the human readable format in order to check what information a custom configure file generated.
Or more generally, the classic way to make the pkg info if you were not using the "simple" cabal build system, but were using configure + make (e.g. wrapped in the cabal "make" build-type) was to generate the input file using configure/m4 text substitutions. So that did/does need to be human readable. As for the binary format, that's ghc's internal representation and not something I think we would want to standardise between Haskell implementations. Note that other Haskell impls use a package database that just uses these human readable files, with no hc-pkg style program. Duncan
On Sun, 2013-03-17 at 19:27 +0000, Ian Lynagh wrote:
On Sun, Mar 17, 2013 at 09:57:25AM -0700, Mark Lentczner wrote:
Is it essential, or even sensical, that the serialization format GHC needs for storing package info bear any relation to the human authored form? If not, the split out of the package types could be accomplished in a way where GHC uses simple show/read(P) style serialization for storage of package info, where as cabal-lib would use a lovely parsec parser for humans. I'd like this approach.
I think it would be feasible to stop GHC itself from using the human readable format. The only place I can think of it being used is in the package database, but we could use either Read/Show for that, or just exclusively use the binary format.
The change in functionality to enable that would be that the binary "cache" would always have to be up to date, so ghc would only ever have to read the cache and never have to read the human-readable package files. Then you can have ghc-pkg depend on Cabal and use that for the human-readable bits, but since that's a program then it doesn't expose the Cabal lib dependency. Then ghc (and hence the ghc lib) would not depend on Cabal, but it would need a copy of the InstalledPackageInfo type and the other types that it uses. Duncan
On Mon, Mar 18, 2013 at 12:34:16PM +0000, Duncan Coutts wrote:
Then you can have ghc-pkg depend on Cabal and use that for the human-readable bits, but since that's a program then it doesn't expose the Cabal lib dependency. Then ghc (and hence the ghc lib) would not depend on Cabal, but it would need a copy of the InstalledPackageInfo type and the other types that it uses.
Right, exactly. But we don't want to have 2 copies of the types, so could we move them into a Cabal-datatypes package which can be shared by both Cabal and GHC please? Thanks Ian
On Mon, 2013-03-18 at 12:43 +0000, Ian Lynagh wrote:
On Mon, Mar 18, 2013 at 12:34:16PM +0000, Duncan Coutts wrote:
Then you can have ghc-pkg depend on Cabal and use that for the human-readable bits, but since that's a program then it doesn't expose the Cabal lib dependency. Then ghc (and hence the ghc lib) would not depend on Cabal, but it would need a copy of the InstalledPackageInfo type and the other types that it uses.
Right, exactly. But we don't want to have 2 copies of the types, so could we move them into a Cabal-datatypes package which can be shared by both Cabal and GHC please?
That would be a rather annoying split. The cabal-lib package itself is supposed to be just types + parsers + pretty printers (& related utils). It'd end up looking like: cabal-types: types: InstalledPackageInfo, PackageName, Version, PackageId, InstalledPackageId, License cabal-lib: parser for InstalledPackageInfo, PackageName, Version, PackageId, InstalledPackageId, License modules Distribution.* cabal-build-simple: modules Distribution.Simple.* It's not as if one could frame this as a "the aspects of the Cabal spec that compilers need" because the other impls will want the parser + printers as well. Duncan
participants (3)
-
Duncan Coutts -
Henning Thielemann -
Ian Lynagh