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.

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.

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

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 {}.

If that's buggy, then there's a larger problem in my opinion.

C comments do not nest.

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

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.

  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 it