A Haskell Newbies' guide to Snap, Part 1 (updated for Snap 0.8)

[This tutorial is now updated for Snap 0.8. It could really use a more thorough overhaul -- the code does a poor job of separating view from model. But I think it still has value in demonstrating the API]  

I've spent a bit of time working up a simple application in the Snap web framework.  This proved to be a bit of a challenge: the documentation for Snap is definitely a work in progress, and doesn't cater well to a Haskell newbie such as myself.  This account is intended to help others in my position get up to speed on Snap, by filling in some of the information that the tutorial's authors may have taken for granted.  It is not intended as a standalone introduction to Snap. If you want to use this document to help you learn Snap, I would suggest the following steps:

• Read the first four Snap/Heist documents in the TUTORIAL section
• Read through this document
• Build an example application

A maze of twisty little Strings, all alike

This post was spurred by a recent discussion of whether or not Haskell code just works the first time you try it.  As a less-than-expert Haskeller, my answer to that is "not so much."  But even as a less than expert Haskeller, I find that my Haskell code needs much less debugging time than when I write in another language.  It feels like a difference of kind, not one of degree.  So I understand where the original claim comes from, even if I ultimately find it to be overstated.  What's great about Haskell is that it has lots of language features that support robust code.  Immutability of data gets lots of press, and deservedly so, but Haskell has many other features that help. 

What this post is about is one of the Haskell techniques that helps me write code that is more solid.  That technique is using type aliases to differentiate amongst the various kinds of strings that I am using. 

A Haskell newbie's guide to Snap, Part 3

This is a followup to Part 1 and Part 2.  Those posts covered the basics of using Snap and Heist, and their APIs for accessing data from the HTTP request and from the splice instance.  This post will show how to access SQL data with the HDBC package (in this case, we'll use PostgreSQL).  Along the way, I hope to give a better picture of how all the pieces fit together (though I'd welcome comments from experienced Snappers on how the code might be improved).  

A Haskell newbie's guide to Snap, Part 2

This post is an overdue followup to Part 1.  I'll try not to repeat much of that material; review that link if you need a refresher.  Here I'll show how to use Snap and Heist to save some data from an HTML form.  That will involve using Snap to pull POST/GET data from the request and then building HTML elements for the page with the Text.XmlHtml library. 

We'll use the same simple cheese database as our background.  This database has four columns: name, country, price, and stock.  We want to have a single page that lets us edit an existing cheese record or create a new one.  There will be two forms.  The first form lets us enter the name to edit/create, and has an Edit/Create button that fills data into the second form.  The second form has text inputs for each of the data columns, and a Save button.  When we first land on our page, we're at /cheese_template.  Pressing the Edit/Create button sends us to /cheese_template?name=Epoisses, and pressing the Save button sends us to /cheese_template?_task=save. 

A Haskell newbie's guide to the Snap framework

NOTE: the updated tutorial for Snap version 0.8 can be found here .

I've spent a bit of time working up a simple application in the Snap web framework.  This proved to be a bit of a challenge: the documentation for Snap is definitely a work in progress, and doesn't cater well to a Haskell newbie such as myself.  This account is intended to help others in my position get up to speed on Snap, by filling in some of the information that the tutorial's authors may have taken for granted.  It is not intended as a standalone introduction to Snap. If you want to use this document to help you learn Snap, I would suggest the following steps:

• Read the three Snap documents in the TUTORIAL section
• Read through this document
• Build an example application

Snap was absolutely easy to install and get running.  The API introduction walks you through creating a hello-snap app from scratch.  The app has a built-in HTTP server that serves a few simple web pages.  My goal was to create a web page that integrated data from a PostgreSQL database.  

If I Were Given a Re-do from the Beginning

I'll get to the title topic in just a minute.   But first, more about Real World Haskell.  Currently I'm a little more than halfway through the book, and still liking it quite a lot.  I'm currently halfway through the "Programming With Monads" chapter.  I'm feeling that this chapter is a little dense with text and that more incremental baby-steps exercises would do it some good.  Certainly they would do me some good.  So I'm stopping where I am until I have time to sit down and write some more monadic code.  I imagine it will take a few repetitions until I'm comfortable with it, but that seems like a fundamental skill if you want to write Haskell. 

Now for the main feature: if I had to do it all over again, here's what I would do to learn Haskell from scratch:

• Start by reading Learn You A Haskell.  All the way through.  
• Really get into some code with Write Yourself a Scheme. 
• Read Read World Haskell from the very beginning, and don't skim through the earlier chapters; they have a different and useful way of presenting the basics.  Yet I wouldn't start here; I learn best when I see a topic from a couple of different directions. I have the dead tree version of the book but there's a free PDF available here.

And here's what I would not do:

• Read Monad tutorials early in the learning process.  I wouldn't recommend it before reaching the monad chapter in Real World Haskell.  First of all, the monad sections in Learn You A Haskell and Real World Haskell are quite good.  Second, monad tutorials are more effective if they are immediately reinforced by some coding exercises. I think the best path to understanding monads is by using the damn things. 
• Read any type theory content until . . . well, past where I am now.  I have read some of this stuff and have yet to see any useful connection to actual Haskell code.  I'm sure I'll get there eventually, but I'm not there yet. 
• Do not start Haskell School of Expression unless you first find the source code and get it running. 

Finally, there's something I might do: read The Haskell Road to Maths, Logic, and Programming.  That book is rather less a book about programming Haskell and more a book about the foundations of mathematics.  If that sounds interesting, then the exercises in the book are a nice way to get some coding practice as you are coming up to speed in Haskell.

Getting More from the Type System

This blog post from Tony Morris really got me thinking about the advantages of a powerful static type system like Haskell's.  That blog post (along with others such as this one) are great pointers for getting the most mileage from the type system.

When I first started with Haskell, I was pleased with the effect that the type system had on the code-test-debug-refactor cycle by keeping the type errors at compile time -- yet not requiring lots of tedious, error-prone boilerplate to support that.  I found that code was much more likely to work with minimal debugging.  Along with the conciseness of the code, this made for a more engaging and satisfying experience at the "hacking" level.  This is more than enough reason to learn Haskell. 

But what I wasn't yet seeing was how to take it to the next level and exploit the type system at the design stage.  Those two blog posts are great examples of how to use the type system at design time.  I coded up a Haskell solution to Morris' exercise, and it was some time well spent.  Example code is below the cut, and I think it's a great little package that shows very directly how Haskell's type system adds value.