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.

The text operators of the release 1.0 of my Haskell PDF library are very low level. You have access to most of the PDF text operators but it means you can just specify where to put a line of text. So, it is difficult to do more than displaying some labels on a chart. The styles are also very limited : you can use bold and italic if it is supported by the standard PDF fonts.

For the 1.1 release of my library, I have decided to improve this and write something cool.

Here it is ! I finally released a version 1.0 of my Haskell PDF library. It is a totally new implementation and a totally new version. But, it is not done yet. There are several other features I'd like to introduce in future versions and some things I'd like to improve. But, I had to release something. I could not wait forever.

Here is a summary of the features with some criticisms. The package is containing a demo in the Test folder.

This blog is very quiet but there is a good reason for it : I am writing a totally new version of my Haskell PDF library. New API and new implementation with lots of new features.

WARNING : This post has no interest :-)

Initially, I wanted to connect a comonadic implementation of the game of life to OpenGL. It worked but I had a space leak (and still have). I am not good at all at finding space leaks. So, I have postponed that comonadic implementation (and perhaps will use arrows in the future).

This is the third part of my serie about Haskell and category theory. In the previous post, I described a bit the Hask category and some categorical constructs. The goal of this text is to understand the meaning of a recursive type like List. For that, we will have to understand what is a free algebra and have a quick look at the relationship with monads (for applications look at the blog of sigfpe). But first, I would like to highlight a problem with the category Hask.

In my previous post, I explained that with category theory you can define some concepts in such a way that they can be used in several different contexts. As a side effect, the definitions are rather abstract since they are forbidden from talking about the implementation of the objects and must rely only on the provided interfaces.

So, a first thing to do when studying category theory is learning some of these definitions. Some of them are just generalizations of ideas commonly used in set theory.

If you like maths you'll love this free software : Group explorer.

Group Explorer helps you visualize groups, homomorphisms, subgroup lattices, and more.

The most common group visualization technique is the multiplication table; nearly every student has seen it and therefore it needs little introduction.

Cayley diagrams are a very potent but underused visualization technique, probably because creating them is difficult by hand. Group Explorer makes them easy to view and edit.

"Category theory" is an expression that is generally frightening people. But, if you have attempted to read some research papers in Computer Science, Mathematics, Physics or even Philosophy, you've surely remarked that Category theory is used a lot and you probably asked yourself : what is Category theory ? Why is it so useful ? Is it so difficult ? What the link(s) with computer science ? Answering to those questions in an easy way that can be understood by most people is really challenging but I am going to try and I'll use the category of Haskell programs to illustrate some points. I hope the expert will forgive me some slight inaccuracies and/or an unconventional presentation.

If you're a functional programmer or an Haskell coder then you won't learn anything new from this post. But, if you're learning functional programming or if you're just wondering why static typing is useful then you can continue reading. People from the dynamically typed language world generally claim that you do not need static typing. It is too annoying and you can rely on unitary testing for similar results. I'd just like to show on a very simple example that static typing is not only very useful but also very convenient. Static typing and unitary testing have both their use.