XSLT: A Pure Functional Language
Some years ago now, I had the pleasure of working with a great team building a very elegant publishing and rendering system for MSN. This was one the best times I’ve had at Microsoft. It was a revolutionary system for the time[1] based on transformation of XML data feeds into rendered modules. The transformation language of choice was XSLT. This was my first purely functional language. I read Michael Kay’s book cover to cover and found it so interesting. Aside from detailing XSLT, he talks quite a bit about the functional mindset:
“The crux of the argument is that it’s the assignment statements that impose a particular order of execution on a program. Without assignment statements, we can do things in any order, because the result of one statement can no longer depend on what state the system was left in by the previous statement. Just as the goto statement mirrors the ‘jump’ instruction in the hardware [he had just talked about Dijkstra’s ‘GoTo Statements Considered Harmful’ article from the late 60’s] , so the assignment statement mirrors the ‘store’ instruction, and the reason we have assignment statements in our programming languages today is that they were designed to take advantage of sequential von Neumann computers with jump and store instructions. If we want to free ourselves from sequential thinking modeled on sequential hardware architecture, we should find a way of describing what effect we want to achieve, rather than saying what sequence of steps the machine should take in order to achieve it.” – Michael Kay
The application of a functional language to transformation is a perfect fit; the output itself being a function of the input. Decomposing the data with template matching is wonderful mechanism. Interleaving data and code in XSLT also dovetails very nicely. It’s the same kind of advantage I see now in Scheme where the line between data and code is so blurred.
XSLT is best for breaking down and transforming an input schema of course, but the “hello world” of functional languages seems to be the factorial function, so here goes (not the most succinct language ):
<xslt:template name="factorial">
<xslt:param name="n" />
<xslt:choose>
<xslt:when test="$n <= 1">1</xslt:when>
<xslt:otherwise>
<xslt:variable name="result">
<xslt:call-template name="factorial">
<xslt:with-param name="n" select="$n - 1" />
</xslt:call-template>
</xslt:variable>
<xslt:value-of select="$result * $n" />
</xslt:otherwise>
</xslt:choose>
</xslt:template>
BTW, here’s a slide deck from an XSLT presentation I gave a while back.
For the past seven or eight years I’ve had a nagging inkling that I’ve been missing out by not seriously digging into functional programming. I’ve thought that as multi-core systems and massive datacenters become more prevalent, functional programming will become a necessity in order to scale. Just like Google revived[2] the age-old idea of AJAX, when I read about things like MapReduce (and Dryad), I’m hoping for a revival of functional programming.
I have recently been on a kick learning as much as I can about Haskell, Scheme, F# and the functional things coming in C# 3.0. For the moment I’m busy with Scheme and am really enjoying the Abelson-Sussman SICP Lectures.
[1] Back in the MSN 7 days, before Windows XP had shipped, before .NET 1.0 had shipped, back in the early days of XML adoption – we ended up shipping on a pre-release build of the CLR, wrote everything in C#, ah… the salad days...
[2] We used JSON-like ideas ten years ago and web apps like Outlook Web Access have used XMLHttpRequest to pull data without refreshing the page for many years, but when Google uses if for maps suddenly AJAX is born.