Composing Lambdas in C++14 -- and Functions, Too!

In my most recent post, I mentioned the interesting lambda changes coming in C++14 (aka C++1y). This post will follow up on that, and provides some methods for exploiting those new lambdas. The C++14 lambda functionality is already available in Clang 3.4; all the code in this post was tested with that compiler.

Last time, I gave a shout out to this blog post by Sumant Tambe, who listed a number of very interesting things enabled by the draft standard. There's one significant new usage that Sumant didn't remark on, though, and that is composition. The new feature that enables these usages is generic lambdas, which are declared with a type of auto. The compiler uses template argument deduction to build the actual type of a generic lambda; that actual type is an anonymous template.

The New C++14 Lambdas

This post isn't directly Haskell related, but should be of interest to C++ programmers who like Haskell.
So I've had a look at the new C++14 Lambdas. I'm still absorbing them, but they definitely are a big improvement over the C++11 version. See this blog post by Sumant Tambe for a first taste.
A clear win here is that std::bind, that gawdawful mess, is a thing of the past. You can assign lambdas to auto variables, you can return them directly -- they are darn near really and truly first class. There's a way to define 'id' and some ways to make it useful. You can compose functions, too. Though you have to define the composition operator yourself, and I suspect that you will get template error hell if you mismatch your types. We will have to see what Clang can do about that.
It doesn't look like the standard itself adds any support for function composition, maps/folds, and such. But it does look like those are all attainable, so I fully expect to see some supporting libraries coming out from the likes of Boost. With luck, they will even be in the Standard Library for C++17 or C++20.
Next up, typeclasses!
Sadly joking about that last one. Concepts Lite seems to have been put off until at least C++17.

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.