Past and Future libraries
June 18, 2008
Hello planet, as my first post that gets placed on planet.haskell.org I decided to do a quick recap of the libraries I maintain and muse about future libraries. My past posts include why static buffers make baby Haskell Curry cry and fun academic papers.
The Past
* pureMD5: An implementation of MD5 in Haskell using lazy ByteStrings. It performs within an order of magnitude of the typical ‘md5sum’ binary, but has known inefficiencies and could be improved.
* ipc: A trivial to use inter-process communication library. This could use some work, seeing as structures that serialize to over 4k get truncated currently. I’ll probably only come back to this if I end up with a need for it.
* control-event: An event system for scheduling and canceling events, optimized for use with absolute clock times.
The Present
* hsXenCtrl: This library is intended to open the doors for Haskell apps to interact with and perhaps manage Xen. Currently its just straight forward ‘c’ bindings to an old version of <xenctrl.h>, but the intent is to build a higher level library with useful plumbing.
* NumLazyByteString: Not sure if I’ll bother finishing this one, but it adds ByteString to the Num, Enum, and Bits type classes. I just thought it would be funny to have lazy adding allowing: L.readFile “/dev/urandom” >>= \a -> print (a + a `mod` 256)
The Future
I tend to be a bit of a bouncing ball in terms of what nterests me. Near and mid-term tasks will probably be a couple of these:
* A .cabal parser that can create a dependency graph for Haskell packages (not modules). But should I use an outside package like graphviz or go pure / self contained Haskell?
* An implementation of something distributed like a P2P or ad-hoc networking protocol. Would this be Pastry then Awerbuchs work or OLSR2? These would be large tasks with their own ups and downs.
* Finally learn happs and make some sort of web Xen management system using hsXenCtrl.
* Learn Erlang – just because it looks cool too.
* Forget programming (and blogging) – read more TaPL!
Beware the Jabberwolk 
June 19, 2008 at 2:37 am
Re: future stuff:
.cabal parser: I would just go the pure Haskell route. The GUI stuff is probably handled already by a library like diagrams, and once you’ve parsed the .cabal (the hardest part IMO, the part GraphViz wouldn’t help with), would manipulating the graphs be all that difficult?
P2P: You really need to check out Barracuda and its supporting libraries.
June 19, 2008 at 3:28 pm
.cabal parser: For my honours project in maths this year, I’m actually doing a project which will involve graph-theoretic analysis of Haskell code and modules, quite possibly using the .cabal file to determine what modules to examine. Not sure how much visualisation will be done though.
June 19, 2008 at 10:25 pm
Ivan:
Sounds neat, will you be putting your work on hackage or perhaps a respository at code.haskell.org?
Gwern:
Yes, I ran into that. I’m not sure if I want to implement an overlay/distributed P2P network or an ad hoc network (as in, MANET). I’ll have to read the associated IETF internet draft to get a feel for how this p2p is setup, should be fun!
June 24, 2008 at 11:07 pm
I’m going to get Abuse netplay working, and maybe conceive of a 2D interpolation technique such that I can update server-state 3 times per second rather than every 15 (once per frame).
That means 300ms ping would be acceptable versus the 66ms that’s currently desirable. Think I can get it done this year?