18 ms·
How to read Haskell like Python
- eru 15y agoA set of useful lies. Some of my co-workers were interested in learning to read Haskell, not so much in writing it. Let's see whether they like it.
- antipax 15y agoTo be fair, monadic code does not necessarily have side effects. It's just a useful way of thinking about computational steps. `Maybe` is a monad that is completely pure and has no side effects: http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/Data-Maybe.html#line-76 http://www.haskell.org/ghc/docs/latest/html/libraries/base/s... I understand that this article is geared towards beginners, so this is probably just a simplification on the author's part. Other than that it's a great article.
- xtacy 15y agoYes, I've always thought of Monads as a programmatic way to "compose" computations, or, a "programmable semi-colon."
- jerf 15y ago"so this is probably just a simplification on the author's part." I guarantee that: http://blog.ezyang.com/2011/04/the-haskell-heap/ http://blog.ezyang.com/2011/04/the-haskell-heap/
- joeyh 15y agoThe problem with the simplification is that you really need to understand which monad code is using to read the code. foo >>= bar >>= baz has very different behaviors in the IO monad (it's like a shell pipe foo | bar | baz) and the Maybe monad (it's like a short-circuiting foo && bar && baz).
- ezyang 15y agoNot really... you're perfectly capable of reading Python code: x = foo() y = bar(x) baz(y) Knowing that any of these functions could throw an exception. How is it any different, from the reader's perspective? (Yes, it's /very/ different from an implementation perspective, but that's not what we're dealing with here...)
- andolanra 15y agoThere is a highly theoretical point of view which states that a "side effect" is anything other than a function A → B which takes an A and returns a B. This includes things like exceptions (A → err + B, which is Haskell's Either), state (A → (S → B * S), Haskell's State monad), and Maybe (A → () + B, as mentioned.) In fact, Haskell is only mostly pure, because it contains the nontermination effect (A → ⊥ + B, i.e. functions might not always return a value because of infinite loops.) It's true that most of these "effects" are implemented in terms of pure functional code, e.g. the state monad—which models a very imperative construct—is also pure and has no side effects from the implementation's point of view[1]. The point is that from one point of view, these are 100% pure: "Of course, it's implemented in pure terms, so of course it's pure!" There's another point of view that they're entirely impure: "I'm manipulating state in this function, so of course it's impure!" All of which is to say, if you ignore the plumbing, the water appears out of nowhere. [invocation of Clarke's 3rd law excised for triteness] The same could be said about Haskell itself: "Of course it's impure, because there's a call stack being destructively modified as it runs!" (Conal Elliott went the other way and suggested that C was a pure functional language[2].) It's just that, of all the monads, some of them (e.g. the IO monad, the X monad, &c) use some kind of "magic" to interface with external effectful functions, while other ones mimic state using pure functional constructs. Still—to a programmer, the Cont monad appears to jump throughout your code, making it "effectful" from an appropriate level of abstraction. [1]: http://en.wikibooks.org/wiki/Haskell/Understanding_monads/State#Instantiating_the_Monad http://en.wikibooks.org/wiki/Haskell/Understanding_monads/St... [2]: http://conal.net/blog/posts/the-c-language-is-purely-functional http://conal.net/blog/posts/the-c-language-is-purely-functio...
- rfugger 15y agoWhoa, as a python guy, this makes me not want to learn Haskell at all. The syntax seems as bad a Perl.
- antipax 15y agoIt's not actually syntax. The language allows you to define infix operators, and they're just functions like any other with full documentation searchable on hoogle: http://www.haskell.org/hoogle/ http://www.haskell.org/hoogle/
- JadeNB 15y ago> It's not actually syntax. The language allows you to define infix operators, and they're just functions like any other …. `<-` really is syntax: http://www.haskell.org/hoogle/?hoogle=%3C- http://www.haskell.org/hoogle/?hoogle=%3C-.
- antipax 15y agoYup, I was only talking about the "fish operators" as he calls them.
- ezyang 15y agoTrust me, it's better. Perl achieves conciseness by using global metavariables (e.g. $_, $/, etc.) which are silently updated by functions and that you have to keep track of. Everything here is explicit; there are just lots of symbols...
- chromatic 15y agoCould you give examples of these silent updates in Perl? I'm by no means a Haskell expert, but one of the worst parts of learning Haskell (or reading arbitrary code) is that there's no special syntax for partial application. Certainly that's a benefit in many cases if you're familiar with the signatures of the functions you're using, but it's definitely not explicit.
- samg_ 15y agoFor me, one of the biggest obstacles to understanding lots of Haskell code is opaque infix operators.
- Peaker 15y agoThere aren't that many of them in the Prelude and common libraries. Besides the standard arithmetic ones, only ones I can think of are the "fish" operators, composition dot, and a few arrows. Did you try to learn what they mean, or did you give up earlier than that?
- lubutu 15y agoTo be precise: cons (:), bind (>>=), 'constant bind' (>>), 'flipped bind' (=<<), compose (.), apply ($), strict apply ($!), append (++), and subscript (!!).
- joeyh 15y agoI had never seen $! before, of course it's obvious what it does if you know ! and $. There are patterns like this throughout the operators. There are also the applicatives <$> <*> <$ etc.
- adrusi 15y agoalso in Data.List (which is a fairly common import) there are a few, like (\\) which is list difference ([1, 2, 3, 4, 5, 6] \\ [1, 3, 6] == [2, 4, 5]), and I can't really think of any others. There aren't really that many, though some modules will abuse them. The standard ones make sense.
- price 15y agoFortunately it's easy to look them up: http://haskell.org/hoogle http://haskell.org/hoogle Enter any operator or other name, no matter how crazy the characters involved, and it'll find it if it's in the standard library. This contrasts with resorting to Google to look things up in most languages and despairing because it thinks your burst of punctuation (which is the whole point of the query) is noise.
- mvzink 15y ago> But Haskell programmers are allergic to extra variables. Point-free style, best style. http://news.ycombinator.com/item?id=3233870 http://news.ycombinator.com/item?id=3233870
- kemiller 15y agoI think the "dabbling" phase of learning a language is important, and this is the best intro for Haskell dabblers I've ever seen. Nice work, author.
- yobbobandana 15y agoI've tried to learn Haskell a couple times, and I keep running into the basic problem of not being able to search for info on terms like ">>=". If you don't know what it means, how do you find out? I certainly never knew until reading in this article that they were called "fish" operators. I previously tried to work through 3 or 4 different Haskell tutorials, and still didn't know this. This article seems very helpful for simply enabling someone with Python experience to learn Haskell.
- tel 15y agoIt's also called 'bind' and should be described in any monad tutorial. Hoogle is a great reference for using Haskell and can successfully find the 'fish' operators[1]. [1]http://www.haskell.org/hoogle/?hoogle=%3E%3E%3D http://www.haskell.org/hoogle/?hoogle=%3E%3E%3D
- tikhonj 15y agoThey aren't actually called "fish" operators, as far as I know. ">>=" is pronounced "bind"; all the other ones are related. I didn't have this problem when learning Haskell because I just started by reading "Learn You a Haskell for Great Good"--which is a great book, coincidentally--and never had to google operators.
- 15y ago
- switz 15y agoIs it weird that I know haskell and not python? I think so.