Thinking about what's missing in our library coverage

[Simon Marlow]

On 06/08/2009 12:59, Duncan Coutts wrote:
> On Tue, 2009-08-04 at 12:02 +0100, Simon Marlow wrote:
>> On 04/08/2009 00:59, Ian Lynagh wrote:
>>> On Mon, Aug 03, 2009 at 04:44:32PM -0700, Donald Bruce Stewart wrote:
>>>>
>>>> How would you identify the top, say, 5 libs to add?
>>>
>>> I would not look for libs to add. I would wait for people to come and
>>> tell me that they think that particular libs are worthy of addition, and
>>> then decide whether or not I agree.
>>
>> Ok, to kick things off then, I propose the following:
>>
>> Add
>>
>>    * binary
>>    * getopt
>>    * gtk2hs
>
> Now that's just crazy-talk! :-)
>
> What/where is getopt? It's not on hackage. Elsewhere we've raised our
> concerns about binary. gtk2hs is of course not cabalised.

Hmm, I assumed getopt was on Hackage.  Where is it then?

Aargh!  It's still in base :)  We temporarily moved it out a while ago, 
and then moved it back in.   Forget I mentioned it.

What is stopping gtk2hs being cabalised at this stage?  Is it just work, 
or does it need extensions to Cabal?

>> Also
>>
>>    * keep an eye on text.  We certainly want it, but it's
>>      a young package and there's no text I/O yet.
>
> I'd say go for it. If the current API is good then that's enough. It's
> not clear that there needs to be separate I/O modules for it. I might
> suggest hiding all the fusion modules for starter though.

My concern is API consistency.  The way to get Text from a Handle is 
very roundabout: you need to read as a bytestring and then convert to 
Text using an encoding (and if you want the locale encoding you need 
text-icu I presume).  Whereas the way to get a String from a Handle in 
the locale encoding is just hGetContents.

We need to make the API more streamlined here.  I haven't put a lot of 
thought into it, admittedly, but the first step would be to think about 
how to unify the codec interface, so that both packages can use the same 
codecs.

Perhaps this isn't a showstopper.

>>    * decide which regex package(s) we want
>
> I'd like input from the regex maintainer here. In particular which
> backend do we want in the platform and can we please avoid having more
> than one (if we can't choose how do we expect users to choose).
>
>>    * remove html? (we have xhtml)
>
> On the other hand xhtml seems to be going out of fashion.

Right, but I think xhtml has had a lot more attention over the years. 
Perhaps it should have the option to produce HTML - after all if you 
drop the XML header you're nearly there.

Haddock has its own local copy of html.  I wonder why that is...

>>    * replace haskell-src with haskell-src-exts
>
> Yes, if the maintainer thinks its ready.
>
>>    * remove packedstring
>
> Yes! And editline.

Absolutely.

Cheers,
	Simon