I have been so busy on so many topics that I have not been able to update this blog for a while. In addition to my job, I have had some fun with Haskell, iPhone and biotechnology.

If you want another proof that Haskell is going mainstream, here is one : a Fashion Magazine developed in Haskell. And I am happy because they are using my HPDF library to generate it. The mag is created in an automatic way from the blogs of the 360Fashion Network : a network of fashion professionals who try to give an insider view of the fashion industry. So, expect to see lots of pictures blogged from mobile phones during the fashion weeks.

This post is not about functional programming but about plain old imperative languages (C, Java, Python ... replace the dots with your favorite imperative language). I will try to show that you are forced to invent monads if you want to define the meaning of imperative languages ! I have not yet seen this approach to monads in the blogs and tutorials available on the web so I thought it could be a good idea to say a few words about it.

I am doing some additional experiments with Haskell and web development. In this post, I am looking at the problem of composability for web pages.

I have tested different methods for building a web page and what I don't like is the lack of composability. When I look at most web pages, I see several components with their own state and control flow. But, when I build a web page from those components, the composability on the server side (for the request handlers) is less obvious.

So, I have attempted to build a composable solution based upon the idea of a web object. A web object is something with a state, that can be displayed on a web page and can react to some actions. Web objects must be reusable.

If you read my previous post, you'll be interested by this one. Indeed, I have discovered that the idea introduced in the previous post is working but not practical at all since it does not work with type synonym definitions. But, without synonyms, you can't really write the kind of types required to do http content-type comparison at the type level. By luck, some additional type hacking is solving the problem. Moreover, I think it can be useful to show in a very informal way a few applications of computations at type level. It is not so hard (but not totally trivial. I had to make several experiments to get it right).

In my last post, I was writing about the use of coproduct of free monads to do content-type dispatching in a web monad. It was working but it was not the right approach. I changed everything and introduced a lattice of lists at the type level to track hierarchical dependencies between formats and do content-type dispatching thanks to type information. I also added a few other features to my Web Monad.

From time to time, I continue my experiments with Haskell and web development and try to build my own framework. I will never release anything because I am just exploring a few ideas.

Recently, I experimented with a common problem : when a client is getting an URL, it is communicating the formats it wants with some preference values. The server should return the best format according to what is requested by the client and what is supported by the server.

I finally bought an iPhone after having owned several iMode phones, Nokia phones and a few PDAs. After one week of experiments here is how I would summarize my feelings:

I am pleased to release a new version of my PDF library for Haskell and an example showing what's possible with the library : a magazine generated in an automatic way with Haskell.

The parsing for the magazine has not yet been debugged totally and the image layout algorithm is currently very simple. The text formatting in columns is not always ok because I have not yet implemented an hyphenation algorithm. But, the result, still in beta, is good.

I have finally released HPDF 1.1 with some typesetting features. More details are in this post. It is very experimental but working. I am not happy at all with the API of HPDF but I have no choice. I need, for another project, to add features as fast as possible. I'll think about the elegance of the API later even if I need to change lots of things in HPDF (not really a good development methodology I agree). In addition to the typesetting features, I corrected lots of problems, optimized the code and changed a little bit the image API.