Unrelated: I'm obviously quite biased, but I generally like Haskell code for pseudo code like things, because it does away with a lot of syntax specific cruft, and stays close to the math it's usually talking about.
It was more or less just posted, but I could imagine there is plans for the rest of the content to be ported also. I might help with that if I get any time during Christmas :x
Agreed -- I found Haskell most confusing at first because of the lack of syntax. My brain kept wondering where the rest of the syntax was. Not to be too dramatic, but I think Haskell is kind of like programming "poetry" in this regard.
Go is impoverished compared to Haskell but not when it comes to concurrency. The Haskell analogues for these concurrency primitives seem laborious...and they were even moreso prior to the advent of the `async` library.
A commenter on /r/haskell[0] noted that there is actually a library that mimics Go Channels a bit closer, called GoChan[1]. That said, I think `async` is the idiomatic choice, so it probably makes more sense to keep it.
Which is strange. It should be possible to implement proper CML-style concurrency in Haskell, which is strictly more expressive than the go concurrency model.
I only started Haskell since the 1st day of Advent of Code this year. I didn't see that mentioned much either in the article or other articles, but Haskell is like Python and has significant whitespace to determine scope. The error messages related to this aren't always clear...
The error messages should have improved a bit with GHC 8.2[0], you might wanna check that out if you aren't already using it. For stack that'll mean using the nightlies though (e.g. `resolver: nightly-2017-12-09`).
One thing this doesn't mention, which might be useful to know, is that Haskell is indentation-sensitive. For instance, those examples using "let" won't compile if the lines beginning with "let" and "in" aren't indented.
I'd be interested if anyone knows of a simple guide to Haskell's indentation rules - I still find it trips me up now and then.
That's not really true, at least not in the way Python is. Haskell is actually defined using "braceful" syntax, and that syntax can be used anywhere (and is useful for code generation); on top of that it has Layout Rules[0].
Basically:
Any time a "where", "let", "do" or "of" keyword is not followed by a brace, an implicit one is inserted and the indentation of the next lexeme (non-comment non-whitespace item) is noted[1]
For any subsequent line,
* if it's indented by the same amount as the one noted, a semi-colon is prepended
* if it's indented by less than the noted amount, a closing brace is prepended
A closing brace is also inserted when encountering an illegal lexeme (for the current structure) where a a closing brace would be legal.
[1] except if the indentation of the next non-whitespace lexeme is less than the current indentation level, then an empty block is inserted, and layout processing for the current scope continues
It's as noted above: put an opening brace after the "where", "let", "do" and "of" keywords[0], put semi-colons between (or after both work) "statements" in a given "scope" e.g. declarations (in let and where blocks), clauses (in case/of blocks) and actual statements (in do blocks)
module Main where {
main = do {
let {
a :: Int; a = 8;
b :: Int; b = 3;
};
let { c = a `quot` b } in print c;
}}
You can also format it all on one line, it'll work just fine:
module Main where { main = do {let {a :: Int; a = 8; b :: Int; b = 3;}; let { c = a `quot` b }; print c}}
[0] basically every keyword which opens a non-expression "body", a brace after `case` or `in` is a compilation error as they can only contain a single expression
Yeah, I think the real problem I have is the impossibility of opting out of the indentation style. Not using any indentation or newlines seems pretty extreme. All I want to do is write it like it was C, and that’s not possible (maybe we need yet another extension)
> Not using any indentation or newlines seems pretty extreme.
You can certainly use indentation and newlines, my examples were just demonstrating the ability to "obviously" not invoke layout since there's nowhere layout information can be.
Whether to use layout (braceless) or explicit structuring (braceful) is solely determined by a brace being present after a listed keyword, you can have any whitespace you want around it, and you can make that decision on a keyword-by-keyword basis[0] although it will apply to the entire block, so you can write
module Main where -- no brace, layout rules
main = do { -- brace, no layout
let { a = 3 };
let { b = 5 };
print $ a + b;
}
Now here the let statement (rather than expression) is a bit tricky because if we don't use the braces the ; will bind to the "let" which is not using layout, resulting in a parse error. An alternative — and the way do blocks normally desugar — is to use ; as a separator prefix, a style also used by e.g. Elm:
module Main where
main = do
{ let a = 3
; let b = 5
; print $ a + b
}
[0] this is very very useful when generating code which must surround user-provided code: the generated code can be braceful and the user-provided code can independently use layout without conflicts.
Internally, Python is a lot like that, too - like in Haskell, the lexer adds in brace tokens when the code is indented an unindented, which keeps the grammar simpler. I guess the main difference here is that Haskell exposes the underlying whitespace-insensitive notation to the programmer, too, whereas Python keeps it hidden.
I once downloaded a python script, ran it with some input, and got a result. Curious, I opened the script in Emacs, which then opened it into python mode. As is my habit, I indented the whole file, which did basic white space changes to it according to python mode. I didn't realize I did this at first, and I saved and exited the script, then played around with it some more. Still got results, everything seemed the same. But when I tried it with the same input as originally, it was a different return result. This took a while to figure out, until I realized that emacs changed the indentation of just one line, because the author had apparently not followed the typical idioms or conventions of indenting python in some way. That merely opening, beautifying, and saving a file could change program output with no errors has turned me off of white space sensitive syntax ever since.
Which is partly why OCaml gets some bias from me over Haskell.
honestly it's bananas. I can't for the life of understand how such a poor form over function decision was ever made by an engineer. the number of bugs (>0) this introduces into production code every year is reason enough (imho the only relevant metric) to prefer braces. are block delimiting braces really that onerous???
Because braces don't introduce bugs? You can just as easily omit braces in a if/for etc statement and have a bug, or close the wrong brace at the wrong point (and also introduce a bug).
I'm not entirely sure if you are implying that wrong indentation in Haskell will result in programs that compile, but give differing output? I have honestly never seen that happen, and couldn't imagine a piece of code that would compile in either cases.
EDIT:
1) as masklinn mentions, the indentation in Python and Haskell works differently. Furthermore, Python can have expressions as top-level, which Haskell cannot, and you can also have if statements with no else in Python, which again, in Haskell you cannot.
2) I know of no formatters for Haskell which will change the semantics, since they all rely on rendering an AST of the code (IIRC).
3) Ocaml is also white-space sensitive, so I don't see the point in the comparison there?
4) You would need to have some pretty contrived code for it to both satisfy the parser and type-check and be wrong logic caused by moving an indentation.
Like, you can't do it in a function that's a if-then-else plainly, nor a case-statement. Maybe a where statement, but then you just promoted the function to top-level, which will not be a problem unless it's shadowing something else, for which you'll get a compiler warning.
Show me some code, and then I'll consider the point valid, I just can't come up with any examples.
I'm not sure that's what GP meant. I understood what he said as "it's hard to write code which correct in logic, types, and which passes correct beautifier which changes logic", and I'd think this is impossible.
The example you gave requires to change logic - because indentation is a part of the logic here.
Ocaml isn't whitespace sensitive (other than in the obvious sense, i.e., to separate tokens). You can write a whole module (or series of modules) on a single line if you want to.
Really? How do you put multiple "import" statements on a single line in Haskell? Or a function signature followed by its definition?
Ocaml uses whitespace (including newlines) for exactly one reason: token separation. Indentation and line breaks are arbitrary, and can be replaced with spaces in any sequence of Ocaml statements. The same cannot be said for Haskell.
You used a buggy beautifier that mishandled some code, and you blame significant whitespace?
For that to be valid criticism, it must be particularly hard to write a beautifier for languages with significant whitespace relative to other languages.
I don’t think it is. Beautifying C, for example, also can be tricky in the presence of nested comments (potentially of different types) and nested if statements, some without else clauses, some without {}.
That is his point, I think. He doesn't want to be exposed to errors related to whitespace in the code. I feel the same way, and it's the number one reason I avoid Python.
Python and emacs are both popular, and I'm talking about default indent behavior for python in emacs, not some fringe or esoteric plugin for beautifying.
If that's buggy, then there's a larger problem in my opinion.
Which shows what most people prefer. None the less your concern is more than valid and a real problem.
My suggestion would be that the interpreters/compilers of white-space sensitive languages should implement the beautifying operation and call it before code is executed and editors should use this function. We can't expect to not adapt editors to different code styles.
In 1965, Peter Landin presented the groundbreaking paper "The Next 700 Programming Languages" at the ACM Programming Languages and Pragmatics Conference in San Dimas.
It described a family of languages called ISWIM, with a staggering number of durable inventions. It's widely recognized as the precursor to ML and Haskell. One of the inventions is the "off-side rule" for indentation sensitive parsing.
The last section of the paper, after the author's conclusion, is a transcript of the discussion at the conference. The first question is from Naur:
Regarding indentation, in many ways I am in sympathy with this, but I believe that if it came about that this notation were used for very wide communication and also publication,you would regret it because of the kind of rearrangement of manuscripts done in printing, for example. You very frequently run into the problem that you have a wide written line and then suddenly you go to the Communications of the ACM and radically, perhaps, you have to compress it. The printer will do this in any way he likes; he is used to having great freedom here and he will foul up your notation.
Next, Floyd:
Another objection that think is quite serious to indentation is that while it works on the micro-scale—that is, one page is all right—when dealing with an extensive program, turning from one page to the next there is no obvious way of indicating how far indentation stretches because there is no printing at all to indicate how far you have indented. I would like you to keep that in mind.
There were problems with printing APL programs - those strange symbols. Or unclosed brackets and quotes. J tried to address these issues, it's ASCII-only - yet J code still looks rather unstructured.
This argument may sound like admission of imperfectness of printing process.
Last time that I printed a program to work on it was probably 25 years ago..
I don't really think that it makes any sense at all as of today.
And if you are really indenting so much that you can't understand the indentation then it's a clear sign of something wrong in your code.
Please be considerate towards the visually impaired, and don't break zoom on one of the few browsers that actually even have a somewhat useful zoom function!
While I agree STRONGLY, I just tested after seeing your comment and it led me to try the Reader mode in FF which worked perfectly and thus allows full zooming of this site.
Haskell is one of the few major languages I haven't used much. I find this to be very helpful. Sometimes I look at the Pandoc source and wonder what the hell I'm looking at.
`+-` here is an entirely new operator though. The shuffling of arguments might look a bit weird though, it could also be written
(+-) x y = (x + x) - (y + y)
Symbol operators are automatically infix though, and you can make them normal using (), same as backticks make normal functions infix, `a la 2 `plus` 3.
Haskell can be very readable and elegant, but what I do find frustrating is when research papers show sample Haskell, but it's not quite Haskell. They just can't seem to resist the urge to replace various operators and types with their own non-alphanumeric symbols, thus making what should be reading simple code into some kind of hieroglyphic translation exercise..
There are a bunch build into the language, I think a lot of libraries take their queue from there. Still, after you get over the initial hurdle of like <$> == fmap. It's not so bad.
> when research papers show sample Haskell, but it's not quite Haskell
For the most part the code in the research papers actually _is_ valid Haskell, provided you enable the -XUnicodeSyntax extension and include a few extra modules. Haskell 98 permits Unicode symbols and identifiers; the extension covers the handful of symbols which are built in to the language or enabled by other extensions. You can find a full list here: https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...
Personally I prefer Unicode symbols and tend to use them whenever possible. I have some XCompose rules configured to make them easier to type. Unfortunately, I have yet to find a comparable input system for Windows.
I can't link to the slide because of the way these pages are defined:
slide 11:
The presented argument order in the ASCII-art of Red, Blue, Green I think should be Red, Green, Blue to match the usual initialism.
I could not find a way to submit a pull-request for this presentation, and my search-fu on github failed to find the associated repo, and there were no links I could find in the presentation to submit comments.
81 comments
[ 3.0 ms ] story [ 82.6 ms ] threadAlso, readers might be interested in A Tour of Go in Haskell, which is the concurrency chapter of A Tour of Go, but just...in Haskell - https://a-tour-of-go-in-haskell.syocy.net/en_US/index.html.
I realized pretty early on all these were just functions, that was cool experience for me. Even the types are sort of functions.
add :: (->) Int Int add x y = x + y
[0] https://www.reddit.com/r/haskell/comments/7ilhb9/a_tour_of_g...
[1] https://hackage.haskell.org/package/gochan-0.0.2/docs/Contro...
[0] https://twitter.com/raichoo/status/825045995490795521
I'd be interested if anyone knows of a simple guide to Haskell's indentation rules - I still find it trips me up now and then.
The "simple" way I deal with it is to use Emacs and press TAB until things look right :)
That's not really true, at least not in the way Python is. Haskell is actually defined using "braceful" syntax, and that syntax can be used anywhere (and is useful for code generation); on top of that it has Layout Rules[0].
Basically:
Any time a "where", "let", "do" or "of" keyword is not followed by a brace, an implicit one is inserted and the indentation of the next lexeme (non-comment non-whitespace item) is noted[1]
For any subsequent line,
* if it's indented by the same amount as the one noted, a semi-colon is prepended
* if it's indented by less than the noted amount, a closing brace is prepended
A closing brace is also inserted when encountering an illegal lexeme (for the current structure) where a a closing brace would be legal.
[0] https://www.haskell.org/onlinereport/haskell2010/haskellch2....
[1] except if the indentation of the next non-whitespace lexeme is less than the current indentation level, then an empty block is inserted, and layout processing for the current scope continues
You can certainly use indentation and newlines, my examples were just demonstrating the ability to "obviously" not invoke layout since there's nowhere layout information can be.
Whether to use layout (braceless) or explicit structuring (braceful) is solely determined by a brace being present after a listed keyword, you can have any whitespace you want around it, and you can make that decision on a keyword-by-keyword basis[0] although it will apply to the entire block, so you can write
Now here the let statement (rather than expression) is a bit tricky because if we don't use the braces the ; will bind to the "let" which is not using layout, resulting in a parse error. An alternative — and the way do blocks normally desugar — is to use ; as a separator prefix, a style also used by e.g. Elm: [0] this is very very useful when generating code which must surround user-provided code: the generated code can be braceful and the user-provided code can independently use layout without conflicts.tree ="
Which is partly why OCaml gets some bias from me over Haskell.
so you're saying braceless ifs and fors are bad? yes I agree.
> close the wrong brace
-/+ 1 flipping the right number of braces to get that kind of bug is much much harder than indenting a block incorrectly
Maybe, but enclosing an additional statement or more in your brace because you visually indented it incorrectly is just as easy as in Python.
And if you didn't indent it incorrectly, then it's still possible: whereas in Python it's not:EDIT:
1) as masklinn mentions, the indentation in Python and Haskell works differently. Furthermore, Python can have expressions as top-level, which Haskell cannot, and you can also have if statements with no else in Python, which again, in Haskell you cannot.
2) I know of no formatters for Haskell which will change the semantics, since they all rely on rendering an AST of the code (IIRC).
3) Ocaml is also white-space sensitive, so I don't see the point in the comparison there?
4) You would need to have some pretty contrived code for it to both satisfy the parser and type-check and be wrong logic caused by moving an indentation.
Like, you can't do it in a function that's a if-then-else plainly, nor a case-statement. Maybe a where statement, but then you just promoted the function to top-level, which will not be a problem unless it's shadowing something else, for which you'll get a compiler warning.
Show me some code, and then I'll consider the point valid, I just can't come up with any examples.
(Note that compiler warnings give a hint about the bad idea in this code, but nested do's can have this problem without warnings also.)
The example you gave requires to change logic - because indentation is a part of the logic here.
Ocaml uses whitespace (including newlines) for exactly one reason: token separation. Indentation and line breaks are arbitrary, and can be replaced with spaces in any sequence of Ocaml statements. The same cannot be said for Haskell.
With semicolons and curly braces; Haskell's newline/indent syntax is merely an aesthetic substitute for those.
For that to be valid criticism, it must be particularly hard to write a beautifier for languages with significant whitespace relative to other languages.
I don’t think it is. Beautifying C, for example, also can be tricky in the presence of nested comments (potentially of different types) and nested if statements, some without else clauses, some without {}.
C comments do not nest.
If that's buggy, then there's a larger problem in my opinion.
Actually, in Haskell too, but as the GP said, it is almost impossible that it becomes a problem on practice.
Sounds like you made a mistake, then, because indentation is optional in Haskell: https://en.m.wikibooks.org/wiki/Haskell/Indentation#Explicit...
It described a family of languages called ISWIM, with a staggering number of durable inventions. It's widely recognized as the precursor to ML and Haskell. One of the inventions is the "off-side rule" for indentation sensitive parsing.
The last section of the paper, after the author's conclusion, is a transcript of the discussion at the conference. The first question is from Naur:
Regarding indentation, in many ways I am in sympathy with this, but I believe that if it came about that this notation were used for very wide communication and also publication,you would regret it because of the kind of rearrangement of manuscripts done in printing, for example. You very frequently run into the problem that you have a wide written line and then suddenly you go to the Communications of the ACM and radically, perhaps, you have to compress it. The printer will do this in any way he likes; he is used to having great freedom here and he will foul up your notation.
Next, Floyd:
Another objection that think is quite serious to indentation is that while it works on the micro-scale—that is, one page is all right—when dealing with an extensive program, turning from one page to the next there is no obvious way of indicating how far indentation stretches because there is no printing at all to indicate how far you have indented. I would like you to keep that in mind.
It's a very old discussion.
This argument may sound like admission of imperfectness of printing process.
Please be considerate towards the visually impaired, and don't break zoom on one of the few browsers that actually even have a somewhat useful zoom function!
[0]: https://github.com/soupi/rfc/blob/master/reading_haskell.md
https://github.com/soupi/rfc/blob/master/reading_haskell.md
I should learn Haskell (again).
[0]: https://haskell-lang.org/tutorial/operators
For the most part the code in the research papers actually _is_ valid Haskell, provided you enable the -XUnicodeSyntax extension and include a few extra modules. Haskell 98 permits Unicode symbols and identifiers; the extension covers the handful of symbols which are built in to the language or enabled by other extensions. You can find a full list here: https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...
Personally I prefer Unicode symbols and tend to use them whenever possible. I have some XCompose rules configured to make them easier to type. Unfortunately, I have yet to find a comparable input system for Windows.
I can't link to the slide because of the way these pages are defined:
slide 11: The presented argument order in the ASCII-art of Red, Blue, Green I think should be Red, Green, Blue to match the usual initialism.
I could not find a way to submit a pull-request for this presentation, and my search-fu on github failed to find the associated repo, and there were no links I could find in the presentation to submit comments.
You can find the document and repo here:
https://github.com/soupi/rfc/blob/master/reading_haskell.md