How to Breathe, Functionally (part 2)

In a previous post, I pointed out some ways that you can acheive the "compute this, now save it and compute this, ..." style of coding in a functional language such as Haskell without going mad. This is a continuation of that post.

There's one other purely syntactic feature of Haskell that I rather like for readability: Haskell lets you define variables after you use them.

GoToTheNextTrickyBit someVal
   where someVal = DoThisAndThisAndThat...

Although it isn't always appropriate to do this, there are times when I find it extremely intuitive to define my variables after they're used. For instance, to take a "practical" example, compare

mailTo customer =
   let customerName = getCustomerName customer
       customerAddr = getCustomerAddr customer
   in
       makeMailingTo customerName customerAddr

with

mailTo customer = makeMailingTo customerName customerAddr
   where
      customerName = getCustomerName customer
      customerAddr = getCustomerAddr customer

I don't know about anyone else, but when I read the first definition I mentally go "huh. Why are we extracting the customer name?", then skip down to where the name gets used, and finally re-parse the name in that context. The "where" form lets me write the code in the same order that I would read it, giving the code a natural flow. It's very important, of course, to keep the number of auxiliary definitions small; otherwise you leave too many "open questions" for the reader of your code to carry around as she works her way down to the definitions.

But it isn't all roses at the low syntactic level. IMO, the biggest practical problem with writing Haskell code is the syntactically significant indentation.

Python, of course, also has significant whitespace -- but it works mainly because it's extremely simple. Any line ending in a ":" introduces a new block, and statements within a block have the same amount of indentation. In contrast, Haskell's rule...well, just read that link above. You can write code that has the same meaning under any indentation, but it's not idiomatic to do so -- and worse, since the statement terminators are not obligatory, a missed terminator might work fine, might change the meaning of your code, or might fail to compile in an obscure way.

A side effect of the complicated indentation rules in Haskell is that the Emacs Haskell mode doesn't work very well at indenting my code. It usually chooses an indentation that I don't want, and often one that doesn't even compile. I'm sure Emacs could do better, but I would be willing to live with a little more punctuation if it meant that the code was easier for programming tools to process correctly. Functional coding advocates assert, correctly IMO, that side-effects are problematic because even smart programmers will write more bugs in their presence. I think the same logic should apply to syntax: making the language harder for humans and machines to parse has negative overall effects, even if it is possible with sufficient effort to parse it correctly.

I think that conceptually, Haskell is a great language -- the problems I see with it are issues of syntax, tool support, libraries and speed (laziness has a high price). Oh, and also the fact that, as with most programming languages that are pleasant to use, you can't get a real paying job writing in it unless you have a PhD. :-(