Coming off years of C/C++ programming, my mind is organized so that I want to write functions such that most important argument comes first in the argument list. But, in a language like haskell, that’s not always the best way.

Here’s an example from just a moment ago. I was adding haddock documentation to some haskell libraries I had written, when I came across this little utility function I had written a while back:

percent_within_range val low high =
     (val-low) / (high-low)

This function takes a value, along with the highest and lowest boundaries of a range. It returns the percentage that the value is above the low of the range. So, passing in 5 0 10 returns 0.5, since 5 is 50% of the way between 0 and 10. 10 0 10 returns 1.0. get it?

Anyway, it was natural for me to pass the val first, since that’s the item I care about when I call the function. In an OO language, percent_within_range might even be a method on val! But, in haskell, this is really the opposite of what you want.

I re-wrote the function this way:

percent_within_range low high val =
       (val-low) / (high-low)

… which is just a re-ordering of the arguments. Now, if you are just calling the function, this makes literally no difference. But, in haskell, this ordering makes it easy to define curried versions of the function like this:

pct_100 = percent_within_range 0 100

… or just use it curried directly:

map (percent_within_range 0 100) lst

You can see this style of argument ordering all over haskell (and other functional languages) libraries, and doing something different is an easy way to mark yourself as an fp n00b. I’ve finally become accustomed to writing code this way, and am still finding examples of “backwards” argument lists in code I wrote long ago.

[EDIT: Since all the comments talk about 'flip' and other strategies for rearranging elements, I want to say that: yes, there are plenty of ways to rearrange arguments, if you are faced with a function that does not curry naturally for your needs. That's not the point. The point is, with some thought, you can make occasions where you need such workarounds relatively rare. After all, I've needed to use ((flip map) [1..10]), but I’ve used (map (+1)) quite a bit more often! I was pointing out that usually the best argument order for common currying is not the order that a lot of imperative/OO programmers would choose.]

A lot of my day-to-day haskell scripts produce html that’s intended to go on my stock market blog. Because I generally just hack stuff together, I’m producing the html along with the output via hPutStr. If I wanted to be a little more fancy and pure about it, I would put another step between my domain and the final HTML output. Looking at the hierarchical haskell libraries, I see Text.XHtml just waiting for me to use it.

So, I played with it for a few minutes. Here, for my own reference, is a very basic use of Text.XHtml:

import Text.XHtml.Strict

myheader = thetitle << "My First Page"

mybody = (h1 << "First Off...") +++
         (paragraph << "Hello, there!")

myhtml = (header << myheader) +++ (body << mybody)

main = do
       putStrLn $ showHtml myhtml

You can also use showHtmlFragment to get a just the html you wrote, with no doctype stuff prepended. I was surprised that it doesn’t seem to put the <?xml … > tag at the top, since it’s xhtml, after all. But, it doesn’t.

Had I been familiar with this library when I wrote all those scripts, I would have used it. Since I wasn’t, I didn’t, and I’m not sure it’s worth my time to replace that stuff now. Maybe, whenever I update one of them, I’ll go ahead and convert it. That way, they’ll eventually all get converted… you know… lazily. And what could be more in the haskell spirit than lazy conversion