3 ms·
While programming in Haskell I also struggled with Haskell's brand of whitespace indentation, even though I come from Python. The key difference in usability be
by partition 16y ago
While programming in Haskell I also struggled with Haskell's brand of whitespace indentation, even though I come from Python. The key difference in usability between Python's whitespace indentation system and Haskell's indentation system is that you cannot start the lines in a block on the same line as the block.
Python's is more restrictive: you must skip a line before starting a multi-line indented block; i.e., this is not legal:
if a == b: print "asdf"
print "a"
else:
print "a"
This lets you decide on a very simple rule for dealing with whitespace indentation: Each new block is started by inserting a carriage return and the proper number of tabs.
Not so in Haskell, because you are given the freedom to put the first line of a block in the same line as the block starter:
let x = 1
y = 2
do x <- 1
y <- 2
Now you need to decide whether to be 3 or 4 spaces in depending on whether it is a let or do block. You cannot use the rule, because the appropriate number of spaces is no longer a multiple of your indentation unit.
That's just the simple case, because you are also allowed to put these block starters (let, do, case, etc) at arbitrary points in an expression:
f = let x = 1 in let y = x + 2 in
y + 1
This is syntactically correct Haskell; but personally I like the idea of lexical scope being represented by indentation level, which is not reflected here.
It becomes very easy to get yourself into situations where you cannot use the Python rule. But you can also impose restrictions on yourself so you _can_ use that rule. Like always treating let, do, in, etc as "{"'s in C:
f = let
x = 1
in
let
y = x + 2
in
y + 1
This may look a little verbose. But in real cases there would be a lot more statements there. In the middle of all this I want to maintain the idea "number of tabs corresponds to lexical scope". We can also push the analogy to "{"'s in C and adopt the "K&R" style, but on block-starting expressions:
f = let
x = 1 in let
y = x + 2 in
y + 1
There's also the solution of editors that just figure out where to indent, in which case we can make it look pretty and still get the indentation right. I think it's best to develop a consistent style that will work across editors though.
- eru 16y agoWe use OCaml at work, which has similar syntax (although no significant indentation). We explicitly don't intend after the let. Like let a = 3 in f a That seems alright to me, but I wonder why my intuition prefers it.
- Periodic 16y agoMy rule has been to just pad "do" appropriately. Almost everything else works out well with a 4-space tab. Also, don't ever use only one-or-two spaces for indentation, and if you're finding you have a long expression with so much indentation and unindentation that it gets confusing I usually find I'm doing something confusing and should simplify it anyway. For example: let x = y in do something something with ( lots . of . args ) something else Is not that hard to read for me, and actually looks quite nice. And if you're getting those terribly long-expressions, break them up. They can always be broken out in a let expression to be simpler, and with let the precedence is obvious. map (alpha . bravo) . filter charlie <$> xray <|> yankee >> zulu might be better written as let f1 = map (alpha . bravo) . filter charlee <$> xray f2 = yankee result = f1 <|> f2 in result >> zulu Haskell has the ability to write great one-liners, just like Perl, but it takes discipline not to use them. Of course naming your variables descriptively helps a lot too. Examples with single-variable names are probably not the best.
- eru 16y agoYes, but like in Lisp, your Haskell code looks usually better without trailing parens.
- vegai 16y agoAlso, the colon in python's syntax is one of its most important and often disregarded features. It gives such a simple and efficient cue that a new block is.