* Ivan Lazar Miljenovic [2013-03-15 22:12:47+1100]

On 15 March 2013 22:05, Roman Cheplyaka wrote:

...

* Heinrich Apfelmus [2013-03-15 10:38:37+0100]

...

Duncan Coutts wrote:

...

Hi folks,

I want to give you advance notice that I would like to make Cabal depend on parsec. The implication is that GHC would therefore depend on parsec and thus it would become a core package, rather than just a HP package. So this would affect both GHC and the HP, though I hope not too much.

[..]

Why did I choose parsec? Practicality dictates that I can only use things in the core libraries, and the nearest thing we have to that is the parser lib that is in the HP. I tried to use happy but I could not construct a grammar/lexer combo to handle the layout (also, happy is not exactly known for its great error messages).

Reuse is good, but the implication I'm worried about is this: Can I upgrade the parsec package installed on my system by doing a user install from hackage ? Without an implementation of more flexible package installations (multiple versions installed simultaneously), any dependency of GHC has its version number essentially set into stone.

We've had that working for a long time. Right now I even have multiple installed versions of Cabal-the-library itself.

It's not that Parsec would be automatically linked into each executable. It's just that ghc-the-program would have Parsec linked into it.

And ghc-the-library, which means that anything that uses ghc-as-a-library (and indeed even Cabal-as-a-library) no longer has a choice of which version of parsec they use.

Right. But in this regard, GHC API and Cabal are no different from any other libraries that suffer from the same issue. (Except that it's hard to recompile GHC to use an alternative Parsec version.) And these are not exactly the most popular libraries either — so I doubt this change will have a large impact. Roman