On 8/16/08, Antoine Latter <[EMAIL PROTECTED]> wrote: > The following is a summary of my plan so far. I'm interested in > hearing any suggestions or concerns about what a Haskell library for > writing X clients should look like. This is not a release > announcement, and I can't make any promises about when this will be > delivered. > > Code is available in darcs: > -- darcs get http://community.haskell.org/~aslatter/code/xhb > > Some of the advantages XCB claims over xlib are: > + smaller API > + latency hiding when communicating with the X server > + direct access to the X protocol > + improved threading support > + easier to extend > > What I plan for the X Haskell Bindings (XHB) are as follows:
It seems to me that you could make this a bit more haskelly... > + All requests to the server are non-blocking (under most circumstances) > > + Requests which produce a reply from the server return a "token" or > "receipt" Why not abstract this token or receipt into a function? i.e. why not change... > > -- | List all of the extensions supported by the server > > listExtensions :: Connection -> IO (Receipt (ListExtensionsReply)) > > > -- | Query a receipt for a response > > getReply :: Receipt a -> IO (Either XError a) to listExtensions :: Connection -> IO (IO ListExtensionsReply) and then you don't need to use a getReply, or a Receipt data type. This should be equally general, if (as I imagine) the only thing you can do with a Receipt is to getReply it. And to me it seems like a friendly way of describing what this function does. > Each X extension defines its own set of errors and events > (potentially). Should all of these be lumped together into one giant > sum-type for errors and one for events? Or maybe just a couple of existential types together with dynamic? (i.e. like xmonad's SomeMessage) David _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe