Tag : web

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 am a coder and I am very very bad at graphics. I have some friends who are good at graphics but very very bad at programming. And, unfortunately, most web frameworks are using templating systems which are mixing code and html. Either the templating system is useful for graphics and weak on programming or it is providing all the power of a functional programming language but not very easy to use for graphic people.

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).

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.

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.