base package -- goals

Ian Lynagh ian at well-typed.com
Mon Feb 25 17:25:02 CET 2013


On Mon, Feb 25, 2013 at 02:31:56PM +0100, Joachim Breitner wrote:
> 
> Hopefully the problem here (often-changing base) is big enough and the
> alternative (more purpose-oriented and more stable) packages are
> attractive enough to make people use the new set.

I'm pretty confident that most packages won't do more than the minimal
base bumping while importing base continues to work.

> > * base would still be an opaque blob, with too many modules and cyclic
> >   imports, which makes development tricky
> 
> Does it really make development tricky? I’d rather expect it to make
> development easier, because you _can_ mix, say, IO and Foreign stuff
> easily and even use some of that in lower levels. If it were less tricky
> to separate it, then my experiment at
> https://github.com/nomeata/packages-base/tree/base-split would have been
> less work...

It's tricky to make changes to the core modules, because that generally
requires changing imports, and it's hard to see how to actually do that
without making an import loop (or without making more import loops than
are necessary).

In general there's actually a fair amount of flexibility in which way
module imports go (e.g. you can move a "Cl Ty" instance from the Cl
module to the Ty module or vice-versa), but in base it's hard to see how
to structure things best: there are approaching 200 modules, half of
which are tied up in a recursive knot, with 13 hs-boot modules (2 of
which import other hs-boot modules).

> In any case there is still the problem: What and where is the Prelude...
> but maybe let’s postpone this.

I'd put it in its own package for now, and then look at whether/what it
should be merged with later.

I'm in 2 minds about it. On the one hand, I'm sure that lots of people
won't like a single-module package that essentially everything depends
on. But on the other hand, Prelude is both magic and broad, so it would
make some sense to have it in its own package.


Thanks
Ian




More information about the Glasgow-haskell-users mailing list