How to read Haskell like Python

http://blog.ezyang.com/2011/11/how-to-read-haskell

by xtacy • 15 years ago

132 57 15 years ago

blog.ezyang.com

eru• 15 years ago

A 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.

antipax3• 15 years ago

To 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/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• 15 years ago

Yes, I've always thought of Monads as a programmatic way to "compose" computations, or, a "programmable semi-colon."

jerf• 15 years 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/

joeyh4• 15 years ago

The 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).

ezyang6• 15 years ago

Not 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• 15 years ago

There 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/St...

[2] http://conal.net/blog/posts/the-c-language-is-purely-functio...

rfugger• 15 years ago

Whoa, as a python guy, this makes me not want to learn Haskell at all. The syntax seems as bad a Perl.

antipax3• 15 years ago

It'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/

JadeNB• 15 years 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-.

ezyang6• 15 years ago

Trust 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...

chromatic2• 15 years ago

Could 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.

tikhonj7• 15 years ago

That's because this is a very rough, "top-down" description of the language. If, instead of trying to think of Haskell as an inferior Python--which it definitely isn't--you learned it from fundamentals up, all of the syntax would make much more sense.

It's like math: if you just saw something like a triple integral over a weird region with little fiddly symbols everywhere, it wouldn't make sense. If you learned about them starting with the basics, the logic would be clear and elegant.

The other thing is that all the "do" stuff and 'fish operators" are actually really clever and really high-level abstractions--they are basically a unified language for describing all sorts of computations, not just ones with side effects. For just reading most code, this isn't important; for understanding the elegance of Haskell, it is.

agentultra• 15 years ago

If, instead of trying to think of Haskell as an inferior Python--which it definitely isn't--you learned it from fundamentals up, all of the syntax would make much more sense.

This is essentially what I took from the article.

However, I still agree with the OP.

If you are already familiar with the language syntax, grammar, idioms, and so forth then it seems easy and trivial. I find a lot of Haskellers confused as to why anyone finds the language difficult and opaque. Many tutorials and articles are written to convince people that Haskell is easy to learn, I think, because they are familiar with it and desire others to be familiar with it too. Once one is familiar with the language it doesn't matter how dense and difficult it is.

The truth is that Haskell is difficult to learn. One does have to start learning from the fundamentals up because the fundamentals of Haskell are so different from everything else that it's difficult to relate to the previous experiences of most people.

Contrast this with someone who learned C or some dynamic scripting language like Python from the ground-up.. there are a lot of languages with enough shared grammar and vocabulary out there that they can reach out to them without abandoning their previous notions entirely about how programming is done.

Haskell may not exactly ask for one to abandon their notions of computing conceptually but I think it is fair to say that it does ask you to give up all of your previous knowledge of syntax and grammar in order to learn it.

dylangs1030• 15 years ago

As both a Python and Haskell guy, trust me, it's not. The syntax is an example - Haskell code is, in practice, cleaner than presented - some of the article's code is built to example. However, do be aware that languages like Python and Ruby are more friendly to easy reading, by design. Haskell is purely functional, and most designations are immutable. Definition clauses are also combined, which lessens variables (as they're immutable, among other reasons). Don't get turned off because of the syntax. Haskell and Python are useful for different things.

MostAwesomeDude2• 15 years ago

Nah, it's no biggie. What really is rough is the adherence to static types; it's very harsh and can really slow down a person hoping to build things.

And of course, if you're like me, then you don't want to go into a language where there's no Twisted equivalent.

tikhonj7• 15 years ago

I find the static typing actually started helping me once I got used to it. Now almost all of my type errors correspond to errors in logic that I would otherwise have had to find at runtime.

Is Twisted like Node.js? If so, look here: http://stackoverflow.com/questions/3847108/what-is-the-haske...

ezyang6• 15 years ago

I can't tell if you're trolling. GHC Haskell has first class pre-emptive concurrency support. You don't need Twisted because we give that all to you, out-of-the-box, without needing to do anything fancy.

joeyh4• 15 years ago

For a great counterexample, watch the first 10 minutes of this screencast of data-driven programming, in which the the data types for OCR, like PixelData, are first written as essentially undefined, and then refined and changed as needed by the code as it develops. http://www.youtube.com/watch?v=045422s6xik

WildUtah• 15 years ago

Haskell and Perl are actually incredibly close in essential ways.

More literal and decoupled languages like Python or Lisp (or C) mostly work from the inside out in a predictable way where the results of a function don't depend on how or where you use it. Sometimes you couple to a global variable or something but usually that's bad practice and you can be careful to avoid it when it isn't necessary.

Haskell and Perl depend on type systems and context to determine what a function is supposed to do. The expression that receives the result of a function has to be interrogated to determine what the function might do and that can continue recursively. Perl uses $ and @ and Haskell gives you a lot more possibilities than that, but most Haskell depends on the local versions of @ and $ because those are the best contexts, as lwall knew. The context focus can be a nightmare or it can be a perfect concise crystal of exactly what you want but it isn't exactly the acme of separation of concerns. Haskell gives you a lot of rope to hang yourself here.

And then there's the way Haskell and Perl both love their proliferation of syntax, mostly sugar, and special symbols that make them look like line noise until you're an insider at the language club. And even then, they can still be line noise but you aren't supposed to admit it.

(Note: I've written Perl and Haskell programs but not used them for significant projects. Mostly I'm stuck with C++ and Javascript for the same reasons you probably are.)

ezyang6• 15 years ago

There's an important difference you are missing here, though, which is that even if you don't know what specific type context a function is being used in, you still have some very precise information about what the function may do. For example, you may not know what 'mzero' is going to do in this type context, but you do know that it has some specific properties (e.g. mzero >>= f === mzero) and can extrapolate from there.

You'll have similar problems in dynamic dispatch systems: what does this object do? It could do so many things. In Haskell, we demand that the object always follow a certain set of rules. This is very useful.

rayiner• 15 years ago

All the notation is marginally useful when you're writing math on a chalkboard, but saving a few characters in source code isn't really worth it. I like languages that resist the urge to make use of those letters above the number keys.

The fact that Haskell allows libraries to define their own operators is a crime against humanity that justifies the sort of criticism usually leveled at Lisp macros, which is that it's impossible to guess what they mean without looking them up.

chriseidhof• 15 years ago

In other languages I agree, in Haskell it's perfectly normal and no problem. Most of the times, the Haskell code is very readable.

Peaker2• 15 years ago

Operators are just names.

When you're writing very abstract code that operates on abstract structures -- there's often no name that conveys the meaning. English and maths don't have names for every useful abstraction and abstract concept.

Instead of inventing some arbitrary name in English, you invent some arbitrary name as an operator, and that gives you infix syntax (often desirable for binary operators) and a recognizable visual signature.

Also, operators can greatly enhance readability, if you know a certain convention. Consider for example a vector library:

There are various arithmetic operators -- and those can be applied on scalars and vectors. Ordinary arithmetic operators operate on scalars. If < is prepended on the left side of the operator, then the left argument is a vector, and similarly with > on the right side. This makes it easy to immediately know what <+> means, vs what *> means, and so forth.

exDM69• 15 years ago

There's not a whole lot of syntax in Haskell, e.g. no special statements for control flow. What may be a little confusing is the infix operators. Haskell lets you define your own infix operators (which is a good thing compared to a fixed number of user definable operators, like C++ or Python) and there's a few of them you need to know to be efficient with the language (>>= being the most important, $ and . coming second). Exception: <- is not an infix operator but part of the do notation syntax.

Haskell's syntax is very clean and readable, the examples in this article are probably intentionally a bit confusing or at least artificial.

And besides, when looking at a programming language, syntax is the _last_ thing you should look at. The semantics is what is important, by which I mean function calling conventions (fixed vs. curry vs. varargs), type systems (dynamic vs. static vs. inferred), type of evaluation (strict vs. lazy vs. unification) and so on.

Choosing a programming language based on it's syntax is like choosing a wife based on her looks only.

o1iver2• 15 years ago

I would say that understanding composition (.) come before understanding bind (>>=), as bind is like higher-order composition.

samg_• 15 years ago

For me, one of the biggest obstacles to understanding lots of Haskell code is opaque infix operators.

Peaker2• 15 years ago

There 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• 15 years ago

To be precise: cons (:), bind (>>=), 'constant bind' (>>), 'flipped bind' (=<<), compose (.), apply ($), strict apply ($!), append (++), and subscript (!!).

adrusi• 15 years ago

also 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• 15 years ago

Fortunately it's easy to look them up: 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• 15 years ago

> But Haskell programmers are allergic to extra variables.

Point-free style, best style. http://news.ycombinator.com/item?id=3233870

kemiller• 15 years ago

I 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• 15 years ago

I'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.

tel2• 15 years ago

It'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

tikhonj7• 15 years ago

They 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.

ezyang6• 15 years ago

OK OK, "Bind and fish" operators. :-)

joeyh4• 15 years ago

I only think of >=> as the fish operator, and it seems rarely used.

jberryman• 15 years ago

Two very helpful tips:

1. Look at the types of higher order functions (remember, these operators arent magical syntax, just functions) in ghci with ":t (>>=)" for instance.

2. Use hoogle to find the docs for a function, view its implementation, or search for "that one function" by type

P.s. never heard that fish operator business.

gtani• 15 years ago

http://www.imada.sdu.dk/~rolf/Edu/DM22/F06/haskell-operatore...

http://haskell.org/haskellwiki/Keywords

tsuraan• 15 years ago

You want hoogle: http://www.haskell.org/hoogle/?hoogle=%3E%3E%3D

switz• 15 years ago

Is it weird that I know haskell and not python? I think so.

How to read Haskell like Python

Related Stories