Proposal: better library management ideas (was: how to checkout proper submodules)

[Roman Cheplyaka]

* Austin Seipp <aseipp at pobox.com> [2013-06-09 11:15:37-0500]
> Hi Roman,
> 
> On Sun, Jun 9, 2013 at 1:44 AM, Roman Cheplyaka <roma at ro-che.info> wrote:
> > I'm a strong -1 on this. As one example, we have forks of base and
> > ghc-prim for Haskell suite:
> >
> >   https://github.com/haskell-suite/base
> >   https://github.com/haskell-suite/ghc-prim
> >
> > which would be much more complicated if these were not independent
> > repositories.
> 
> I hate being that person but, if the purpose of these forks is to work
> around specific bugs in HSE and/or fix problems with name resolution
> of GHC-specific terms, which sort of seems to be the case from the
> log, I don't think hacking base & co. is a long term solution. It
> could potentially need infinite ongoing maintenance. I went down this
> road with LHC too.

It is only partly to work around bugs in HSE.

The second part is to work around bugs and quirks in base itself. There
are places where CPP wouldn't produce meaningful code unless
__GLASGOW_HASKELL__ is defined, for example.

Even ignoring those obvious bugs for a minute, currently the large part
of base is defined under GHC.* hierarchy and isn't available unless
__GLASGOW_HASKELL__ is defined.

But okay, let's suppose that at some point everything is fixed and we
don't have to *fork* base.  We still would like to use it! Should we
fetch the whole GHC tree in order to get its development version?

> And my gut feeling is that hacking ghc-prim out-of-band feels so
> amazingly wrong I'm frankly not sure if "I need to fork it" can
> actually warrant a huge amount of sympathy, to the point of keeping
> the repository separate for that 1 fork in existence (granted,
> ghc-prim is still pretty low traffic. But base is not.)

It *is* wrong, but who is to blame that a big part of Prelude comes from
there, including all logical operations and classes Eq and Ord?

> If you DO need help from GHC, is there really nothing we could easily
> and reasonably do to further assist you? I think asking for specific,
> principled solutions on our part is not out of the question here.

The best help would be to make and keep base relatively portable and not
to introduce superfluous conditional compilation. (I realise that a lot
of that has just accumulated historically, but now is a good time to get
rid of it.)

It is a ton of work, and I'm very happy when I see people like Joachim
trying to do something in that direction.

Right now I'm only asking not to make their work even harder by moving
base under the ghc repository.

> > But more generally, I think there's still hope that the core packages
> > will be made portable — I'm referring to Joachim Breitner's work on
> > splitting the base.
> 
> To be clear, packages and their numbers aren't *really* the problem.

What I'm trying to say here is that there's hope for a portable base.
Maybe not in the form of split base — I don't know.
But it's the direction we should be moving anyways.

And usurping base by GHC is a move in the opposite direction.

Roman