Advance notice that I'd like to make Cabal depend on parsec

Ian Lynagh ian at well-typed.com
Sun Mar 17 20:27:41 CET 2013


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




More information about the Libraries mailing list