Haskell Platform Proposal: add the 'text' library

[Duncan Coutts]

On Tue, 2010-10-05 at 20:29 +0100, Malcolm Wallace wrote:
> On 5 Oct 2010, at 19:18, Bryan O'Sullivan wrote:
> > Well, if that's the consensus, then we're at an impasse, because the  
> > libraries process is a trackless mire as has been fairly clearly  
> > demonstrated over the past few days, and I'm not going to change the  
> > names or types of the text functions. I've got better things to do  
> > than slog through such an ungratifying and demoralising morass.
> 
> But if someone else were to track down all the name inconsistencies,  
> fix them, and submit a patch to you, would you accept it?

I've not followed the entire thread but perhaps it has not been
discussed sufficiently clearly that it is not a question of accidental
inconsistencies. There was (and imho correct) choice to make the primary
mode of operation on Text be substring rather than element based. Thus
the substring options get the primary names and predicate versions that
operate on elements get secondary names.

It's also not at all clear to me (as someone with both an interest in
bytestring and text) that it makes sense for bytestring to change to be
substring based. It's plausible but it seems to me to make more sense to
keep bytestring's operations element (ie byte) based rather than
substring based.

If everyone else thinks that it's vital that the same name in text be
element based then we do have a tricky question with naming. We do want
the primary operations to be substring, not element, so we would have to
come up with some naming convention that lets us have sensible names for
the primary operations while still having (much less useful) element
based ones.

> I've also been thinking, how come new packages in the HP are held to
> higher standards than the existing ones?  AFAICT, many of the current
> packages are in the Platform simply because a ghc hacker once decided
> to use them (and hence they became widely distributed, regardless of
> quality).  (Yes, I'm looking at you, parsec and containers.)  Sadly, I
> don't have any better suggestions for a submissions process.

We were aware of the problem of the grandfathered packages when we
started. As you say there's not an obvious solution. We don't want to
just say that things keep getting in without enough review. There is
also the opportunity to improve things that are there already, e.g. see
the current proposal to improve mtl. Also, hopefully the higher quality
of the newer packages will embarrass us enough into improving the
existing ones.

As for a demoralising process, perhaps we can make better use of
proposers (as distinct from maintainers). There is also the consensus
protocol [1] described in the procedure. We should also ask the steering
committee [2] to help keep things moving along.

Duncan

[1]:
http://trac.haskell.org/haskell-platform/wiki/AddingPackages#Consensus

[2]:
http://trac.haskell.org/haskell-platform/wiki/Members#SteeringCommittee