Reading Simple Haskell(soupi.github.io)
soupi.github.io
Reading Simple Haskell
https://soupi.github.io/rfc/reading_simple_haskell/
81 comments
Regarding concurrency in Haskell, there is a very good book from Simon Marlow, "Parallel and Concurrent Programming in Haskell".
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.
When I first start I though there was so MUCH syntax, (->), (<*>), (<$>), (>>=), (.), ($), etc
I realized pretty early on all these were just functions, that was cool experience for me. Even the types are sort of functions.
I realized pretty early on all these were just functions, that was cool experience for me. Even the types are sort of functions.
One fun thing is how -> is basically just an infix operation that takes two types as arguments and returns a new type.
add :: (->) Int Int add x y = x + y
add :: (->) Int Int add x y = x + y
It's the function type, data (->) a b. It is commonly written in infix notation though.
[deleted]
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.
[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://www.reddit.com/r/haskell/comments/7ilhb9/a_tour_of_g...
[1] https://hackage.haskell.org/package/gochan-0.0.2/docs/Contro...
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.
This site breaks the zoom function in Firefox.
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!
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.
Wow, thank you for introducing me to that feature!
I'm sorry for that. I'll try to fix this when I can. For now you can view the markdown document instead of the slides here:
https://github.com/soupi/rfc/blob/master/reading_haskell.md
https://github.com/soupi/rfc/blob/master/reading_haskell.md
It doesn’t even work on iOS safari.
You can view this as markdown on github[0]
[0]: https://github.com/soupi/rfc/blob/master/reading_haskell.md
[0]: https://github.com/soupi/rfc/blob/master/reading_haskell.md
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..
> 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.
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.
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.
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.
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.
> Haskell is indentation-sensitive.
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
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
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.
Haskell is also a LOT more lenient. So stuff like
if x < 5
then 42
else x
+ 1
+ 2
I’d honestly appreciate some examples of non-indentation syntax. They’re think on the ground.
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;
}}
module Main where { main = do {let {a :: Int; a = 8; b :: Int; b = 3;}; let { c = a `quot` b }; print c}}
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
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;
}
module Main where
main = do
{ let a = 3
; let b = 5
; print $ a + b
}
Thank you. Need to spend a bit more time grokking this.
Also, comments are considered to be lexemes for this purpose.
> 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 :)
The "simple" way I deal with it is to use Emacs and press TAB until things look right :)
Re indentation, you might find these two useful https://en.wikibooks.org/wiki/Haskell/Indentation and http://echo.rsmw.net/n00bfaq.html.
That helped thanks!
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.
Which is partly why OCaml gets some bias from me over Haskell.
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.
It's a very old discussion.
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.
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.
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.
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.
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.
This example is very contrived, but challenge accepted..
(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.)
main = do
let print = putStr . (++ " ") in do
print "happy"
print "holidays" -- indentation sensitive
putStrLn "!"
(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.)
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.
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.
You can write a whole module in a single line of Haskell too. That's not the correct thing to test.
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.
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.
> Really? How do you put multiple "import" statements on a single line in Haskell?
With semicolons and curly braces; Haskell's newline/indent syntax is merely an aesthetic substitute for those.
With semicolons and curly braces; Haskell's newline/indent syntax is merely an aesthetic substitute for those.
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 {}.
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.
If that's buggy, then there's a larger problem in my opinion.
Beautifying C, for example, also can be tricky in the presence of nested comments
C comments do not nest.
C comments do not nest.
Since C99, you've been able to have end-of-line comments inside a block comment.
Mixing tabs and spaces in Python leads to ambiguities.
Actually, in Haskell too, but as the GP said, it is almost impossible that it becomes a problem on practice.
Actually, in Haskell too, but as the GP said, it is almost impossible that it becomes a problem on practice.
> Which is partly why OCaml gets some bias from me over Haskell.
Sounds like you made a mistake, then, because indentation is optional in Haskell: https://en.m.wikibooks.org/wiki/Haskell/Indentation#Explicit...
Sounds like you made a mistake, then, because indentation is optional in Haskell: https://en.m.wikibooks.org/wiki/Haskell/Indentation#Explicit...
I have never seen a Haskell dev do this.
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.
Simon Peyton Jones, one of the driving forces behind GHC, uses braces.
What did you use to do the indenting?
Just default emacs indent behavior for python mode.
C-x h C-M-\? Or just going through hitting tab on every line? If the first, that was a bug in emacs. If the second, that was a predictable result.
indent-buffer probably is the emacs command unless python mode overwrites that.
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).
>omit braces
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
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
But the requirement for always having brackets is just plain inconvenient for many. Even C doesn't always require brackets.
>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.
Maybe, but enclosing an additional statement or more in your brace because you visually indented it incorrectly is just as easy as in Python.
for (i=0; i<100; i++) {
do_this_100_times();
but_this_just_once(); #oops
}
for (i=0; i<100; i++) {
do_this_100_times();
but_this_just_once(); # oops
}
for i in range(100):
do_this_100_times()
but_this_just_once() # correct indentation takes care of itI can upvote you only once sadly..
I've always been confused when reading Haskell snippets on the web, this really cleared things up for me!
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.
I like the content but:
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.
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.
Thanks! fixed.
You can find the document and repo here:
https://github.com/soupi/rfc/blob/master/reading_haskell.md
You can find the document and repo here:
https://github.com/soupi/rfc/blob/master/reading_haskell.md
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`).
[0] https://twitter.com/raichoo/status/825045995490795521
[0] https://twitter.com/raichoo/status/825045995490795521
x +- y = (x + x) - (y + y)
I should learn Haskell (again).
`+-` 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)
what exactly is crazy about this?
The simplicity with which a new operator is defined.
I think this is a downside. It just makes reading new code that uses esoteric symbols defined elsewhere.
This[0] operator glossary reviews the most used operators.
[0]: https://haskell-lang.org/tutorial/operators
[0]: https://haskell-lang.org/tutorial/operators
This. Incredible elegant. I always enjoy these types of things when programming Lisp.
Nice guide for learning to read Haskell code! You have one minor type: "tree1123 :: IntTree
tree ="
tree ="
thanks! fixed.
nice guide
Also, 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.