“Hello World”, Yesod style…

Here we go! Without further ado, borrowed in part from Developing Web Applications with Haskell and Yesod
(although the discussion that follows is mine, taken from what I now understand about the code).


{-# LANGUAGE TypeFamilies, QuasiQuotes, MultiParamTypeClasses,
TemplateHaskell, OverloadedStrings #-}

import Yesod

data HelloWorld = HelloWorld

mkYesod "HelloWorld" [parseRoutes|
/ HomeR GET
|]

instance Yesod HelloWorld

getHomeR :: Handler RepHtml
getHomeR = defaultLayout [whamlet|Hello World!|]

main :: IO ()
main = warpDebug 3000 HelloWorld

This makes use of several extensions not part of the Haskell standard:

  • Type families
  • Quasiquoting, used for lots of little domain specific languages (DSLs) like the one used to specify the binding between the front controller and handler methods
  • Templated Haskell — a lot of Yesod code generates other code that actually supports your Web application

We’re going to create one data type that’s the foundation of our Web application. In a bigger Web app, this data type would have all the stuff needed for initialization, too — stuff like bringing up a persistent database connection. Our foundation is HelloWorld.

The next bit of code uses the parseRoutes DSL to set up the binding between the Web application’s URIs and the functions that the framework invokes when requests for those URIs come in — the “resource”, as denoted by the trailing R in the function’s name. The syntax is path to resource, then whitespace, then the resource, then more whitespace, then the HTTP method used to access the resource.

We indicate that HelloWorld is an instance of Yesod, the type class encapsulating the behavior of Yesod’s framework.

Next, we declare the resource handling function for /. The framework expects the resource handler to be named as a concatenation of the HTTP method used to access the resource and the resource itself — hence getHomeR is the resource for handling GET requests of the HomeR resource, which we bound to the path /. It’s of type Handler RepHTML, indicating that it returns HTML. Ours uses the whamlet quasiquoter to take an HTML-based DSL and return actual well-formed HTML to the client. As I’ll get into in a later post, you can evaluate Haskell and do other nifty stuff in the context of the various DSLs for content here — it’s pretty cool. Yesod refers to these bits of HTML as widgets, and they can be put in different files so you can have a web page built up of small, reusable widget components, each written in a DSL for HTML called Hamlet.

Our handler just returns Hello World!.

Next up, we have our main function, invoked when the application starts. main uses a built-in web server, Warp, running in this case on port 3000, wired to the HelloWorld class.

We can run all of this using runhaskell helloworld.hs on our local development box, and we’re rewarded with a running Web application on port 3000 — to hit it, start the application in a terminal window, and then go to http://localhost:3000 in a browser window. You can see what HTML the framework produced by choosing “View source”, too.

Apparently, you don’t have to deploy with Warp, although some people do. You can also tether this to a CGI, or even deploy it in a stand-alone WebKit application! This last idea really interests me — you could build a pretty complicated application using Yesod and WebKit, and package it up as a stand-alone binary, I guess. You’d be limited, of course, to what WebKit could present, but with what JavaScript and HTML5 can do together, that’s an interesting way to slap a nice UI on a larger Haskell project, especially if it’s backed by a SQLite database for data storage. I’m going to have to think some more about that.

Next up, expect either some musings on that score, or perhaps a more in-depth look at Hamlet, the HTML templating language! In the mean time, I encourage you to play around with the resource DSL set up by parseRoutes — try adding content to your “application”.

And now for something completely different!

I’ve been dabbling in Haskell since at least 2005, but I’ve never gained fluency. The reason is simple: I’ve never programmed anything of reasonable size in it. I use it a lot for little functional calculation programs, things like utilities for computing the great-circle distance between two points, stuff like that, but haven’t taken the plunge and done anything big enough to really push my understanding forward.

At the Day Job(tm) at Nokia, most of my work is still Qt, with an increasing amount of web technologies (WebGL/HTML 5/CSS/JavaScript) thrown in to visualize results from the research work being done. I feel like I’m stagnating though — I’m comfortable enough with all of those things that I can easily get the job done, and I’m not really learning anything new. Worse, most of the time I feel like I’m writing the same code over and over, parameterized in only a couple of dimensions.

I could lobby for Haskell at the office, but unfortunately that would probably go over like a French kisser at a family reunion — the team has settled on Matlab for prototyping, C++ for performance computation using OpenCV for its vision libraries, Python for data wrangling, and Mongo for databases, with WebGL/HTML 5/CSS/JavaScript and Python in front of the database for data visualization when our older Qt/C++ visualization stuff looks ragged around the edges. I played a part in this decision-making process, and stand by the advice I gave — we’re a cross-disciplinary team with clear objectives in both research and product development, and unfortunately there’s just not room for the hit that coming up to speed and moving all of our existing code to Haskell would take. Moreover, the teams where our code goes after we’re done with it would balk as well — they’re doing some really big compute stuff in Hadoop, and made their bed and will lie in it.

But that leaves me at loose ends; I spent some time working on a book project this winter that’s sort of stalled out (my fault, need to find a publisher and finish it), and looking to sink my teeth into Haskell again. And I think I’ve found the project. There’s a collection of documents from Quakers I want to collect and put in a database, first and foremost for me, but others may benefit as well. Slapping a web front end on the database makes for an easy UI to the database, and would scale well once I collect the data if I decide to share it with other people.

Enter Yesod, a Web framework written in Haskell. It looks to be stable and highly performant, and well-documented, too — some good Web tutorials, and even a book (which of course I’ve already ordered.)

So I’ve decided that rather than using a framework like I know a little about and knock together something in an evening, I’ll stretch a bit and do it in Yesod instead. Building a front end to the database for the data I want to collect in Yesod should get me past the baby steps of writing a few type classes and a bunch of simple functions, with the occasional higher-ordered function thrown in. And, once I get some data in the database, if I decide to open up the data to other users, it’ll need a more robust front end, which requires more bits of Haskell, I’m sure.

In the process, I’ll capture what I do on the project here. It doesn’t pertain to the last book I wrote, or the book before that, but hopefully it’ll be of use to others, and writing for an audience (no matter how small) always forces me to understand what I’m doing better than if I do it alone.

Expect a post or two a week, some weeks more, some weeks less, as time permits. I have some good chunks of time in the next couple weeks to get started, then I go on vacation for a bit — during which either I’ll post a lot less or a lot more, depending on how I feel about things.