Smart, funny, occasionally sarcastic.
A self-describing binary data format for dependently-typed object graphs.
A self-describing data format is a format like XML, JSON, YAML, Amiga IFF, or Common Lisp’s s-expressions, which can be processed at a superficial level without knowledge of the specific type of data it contains. The typical purpose of such formats is interchange across diverse software tools; for example, many tools for working with databases can produce output or accept input in XML. They can also be useful intermediate representations for transformations on data structures, as with XSLT. They can even be used for network protocols, as with XMPP/Jabber. Modern Data is at least as suitable for these tasks as any existing format.
The most distinctive attribute of Modern Data compared to existing formats is that it is dependently typed. In a formal sense, this means that types and values are intermixable. Thus the schema for a Modern Data document is itself potentially a Modern Data document, using a type as a value. Furthermore, bounds-checked arrays, dimensioned quantities, and the like can all be expressed through values used within types, in ways that will be familiar to programmers who have used theorem-proving languages such as Agda, Coq, Epigram, and Idris.
As you can probably tell, I have big dreams for this one.
A Haskell binding to SQLite3. The existing ones were all incomplete and unmaintained, so it was more attractive to do a new one than extend one of them.
A comprehensive low-level solution to serialization and deserialization of formats you don't control. What I mean by low-level is that it doesn't provide instances or dictate formats; rather, it provides a family of related monads with primitives for binary data access.
Using direct-binary-files, you can write code which is polymorphic to the monad it runs in - the same code can run against a file under IO, or against a ByteString as a pure function. This took some very difficult type-system hackery, but I believe the result came out clean!
FruitTart is to be a comprehensive content-management system, featuring such modules as blogging, issue-tracking, and CAPTCHAs. In keeping with the idea that a true craftswoman should make her own tools, I set out to create a bug-tracking database, and wound up creating much more.
FruitTart uses a model-view-controller architecture: The model is low-level SQL code with a powerful query generator, using SQLite3 for all storage, which retains the high performance and clean abstraction of a true relational database while making backup and maintenance operations trivial and requiring no external database server. The controller is native Haskell code with a very clean and well-factored API. The view is a template system; templates are written in a custom template language, which is purposefully minimal for clarity and performance reasons. The template language embraces the ideas of strong typing and simplicity. Queries and templates are stored in the database and edited through a powerful web-based administrator-only interface, just a module like any other.
FruitTart uses role-based access control to support single-logon across all its modules, while restricting users to the areas of concern to them.
FruitTart connects to any webserver that supports the FastCGI protocol.
FruitTart is not yet released, because I don't want the commitment of supporting a legacy version of the API while it is still developing rapidly. However, in the spirit of openness, you can already obtain the source.
Oh, the name? It's thinner than Cake.
This is a teensy tool for Mac OS X that enumerates all machines and services on the local network, using Bonjour, and prints their names. I am aware of programs that do this with a GUI, but I always found myself wanting this information at the command line. So, here it is. I even made a nice installer for you (it uses /usr/local).
A native Haskell implementation of the FastCGI protocol, which allows applications written in Haskell to run as high-performance web scripts, caching such resources as database connections across invocations.
Although the cgi-3000 and fastgci-3000 packages predate direct-fastcgi, I found them to be in a sorry state: They had gone through several maintainers but were not currently maintained, and had several important limitations, such as a complete lack of concurrency, exception handling, and logging. (Actually, they did have some support for all of these things, but none of it worked!) Most importantly, they mismanage the monad, making it very difficult to extend with a user-defined one. Furthermore, they were difficult to build, having the non-Haskell dependency. I was originally going to at least clone their API to make things simpler for people to migrate, but when the time came I realized that my design couldn't be shoehorned into that interface, so I went with an entirely fresh one.
I believe that direct-fastcgi is superior in every way; it is a clean interface, with full functionality. It has clean exception management and well-designed control structure which allows versatility in processing requests which are not simple GETs. In particular, POST of large files should be possible, as should server-push responses which return content a piece at a time. Also, of course, as a native implementation, there is no dependency on a C library, which simplifies the install process.
This one is probably of interest to nobody but me, but I'm proud of it; it's probably the lowest-level code I've ever written. See, I once got my Macbook Pro into a very bad state with a corrupted partition table... Parted couldn't help me, because GPT support was still very new in Parted at the time. I had no access to hardware to get my data off, or to my original install disc to reformat. So over about a week, I wrote this little program which went in and fixed everything up very spiffily!
But instead, I'm just going to refer you to those handy links off to the right!