4 ms·

Syntactically significant indentation doesn't mix well with parentheses. (That's why Python doesn't have multiline lambda, for example.) And Haskell's rules for

Syntactically significant indentation doesn't mix well with parentheses. (That's why Python doesn't have multiline lambda, for example.) And Haskell's rules for indentation are much more complicated than Python's, so the interactions with parentheses are even worse. I'm not sure there's any single person who really understands all the edge cases. It's a complete clusterfuck, they better start afresh. C-style parentheses and curly braces are so much better for parsing, copy-paste, automatically generated code, etc.

chriswarbo 10y ago
> C-style parentheses and curly braces are so much better for parsing, copy-paste, automatically generated code, etc. Firstly, to get this out of the way, you shouldn't be using significant indentation when generating code unless you have a good reason; use parentheses, curly braces and semicolons instead https://en.wikibooks.org/wiki/Haskell/Indentation#Explicit_characters_in_place_of_indentation https://en.wikibooks.org/wiki/Haskell/Indentation#Explicit_c... Now, I wouldn't say parentheses and offside rules "don't mix well", but I'll grant that there are interactions to keep in mind. It's true that Haskell's indentation edge-cases are unfathomable, although thankfully I've never run into any. I have no strong preferences either way regarding significant whitespace, as long as there's an "escape hatch" for code generation (i.e. the braces and semicolons I linked to above). Regarding Python, its lambdas aren't "single line", they're "single expression"; that expression can cover as many lines as you like (e.g. see my SO answer http://programmers.stackexchange.com/a/252546/112115 http://programmers.stackexchange.com/a/252546/112115 ). When learning Haskell, after being a long time Python programmer, I used to think Haskell's indentation rules were complicated. These days, I find it awkward to indent Python code, and end up second-guessing the interpreter a lot. Maybe that's because I'm fond of using 2D code layout and vertical alignment to indicate relationships between lines, which is quite natural in Haskell. Python's indentation seems to be limited to counting blocks, so it's hit or miss whether adding extra spaces to align things will cause it to choke or not.

chriswarbo 10y ago

> C-style parentheses and curly braces are so much better for parsing, copy-paste, automatically generated code, etc. Firstly, to get this out of the way, you shouldn't be using significant indentation when generating code unless you have a good reason; use parentheses, curly braces and semicolons instead https://en.wikibooks.org/wiki/Haskell/Indentation#Explicit_characters_in_place_of_indentation https://en.wikibooks.org/wiki/Haskell/Indentation#Explicit_c... Now, I wouldn't say parentheses and offside rules "don't mix well", but I'll grant that there are interactions to keep in mind. It's true that Haskell's indentation edge-cases are unfathomable, although thankfully I've never run into any. I have no strong preferences either way regarding significant whitespace, as long as there's an "escape hatch" for code generation (i.e. the braces and semicolons I linked to above). Regarding Python, its lambdas aren't "single line", they're "single expression"; that expression can cover as many lines as you like (e.g. see my SO answer http://programmers.stackexchange.com/a/252546/112115 http://programmers.stackexchange.com/a/252546/112115 ). When learning Haskell, after being a long time Python programmer, I used to think Haskell's indentation rules were complicated. These days, I find it awkward to indent Python code, and end up second-guessing the interpreter a lot. Maybe that's because I'm fond of using 2D code layout and vertical alignment to indicate relationships between lines, which is quite natural in Haskell. Python's indentation seems to be limited to counting blocks, so it's hit or miss whether adding extra spaces to align things will cause it to choke or not.