Thinking about what's missing in our library coverage

Axel Simon Axel.Simon at
Fri Aug 7 10:20:51 EDT 2009

On Aug 7, 2009, at 10:58, Simon Marlow wrote:

> 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.

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

I'm no Cabal expert, so Duncan might know more. What Gtk2Hs needs is  
the ability to depend on executables (tools like a modified c2hs)  
that are built by other Cabal packages. Furthermore, we need to  
generate .hs files using these tools. I don't know how difficult it  
is to use Cabal to generate the dependencies and invoke the right  
tools. For instance, a file like .chs.pp is translated to .chs using  
CPP or hscpp, then to .hs and .chi using our own c2hs and then it is  
compiled using ghc. Finally, it seems that we need file-specific  
options in order to compile certain files. I think Cabal has no  
mechanism for that.

I'm sure it's all doable so it probably boils down to a lack of time :-)


More information about the Libraries mailing list