Hacker News Reader

Comment by dreamcompiler | Hacker News Reader

Parens are anything but superfluous. Substituting whitespace for parens is a net loss IMO because indentation errors become semantic rather than merely unaesthetic. And elegant composition is impossible with infix notation unless -- you add parens again.

View on HN

> Substituting whitespace for parens is a net loss IMO because indentation errors become semantic rather than merely unaesthetic.

With good tooling this is not a problem. Try the demos here: http://treenotation.org/sandbox/build/. Make some indentation errors. It's very hard to ignore all the help the editor gives you.

> And elegant composition is impossible with infix notation unless -- you add parens again.

This is a valid criticism. I've seen some folks working on this though, and I expect we'll see a new elegant solution.

  >> And elegant composition is impossible with infix notation unless -- you add parens again.
  > This is a valid criticism.

Is it? What is an example? (One I could think of below seems solvable)

Sorry, I actually think you are right and infix notation isn't a problem (Assigning priorities to operators solves many of the cases, for example).

I was thinking of "elegant composition" of subexpressions. Or, in other words, inline Trees/S-Expressions.

Assigning priorities/precedence rules to operators is a problem. It's a hack to work around the paren-less infix notation not being able to fully describe a tree. It introduces complexity in parsing and it imposes mental overhead on programmers.

You'll note that most code people write in almost any language is prefix anyway. `foo(bar, baz)` isn't infix; it's prefix with the operator placed to the left of the paren.

Agreed. Almost all the code I write is prefix notation. I do like to explore infix languages (and even postfix /concatenative languages as well).

FWIW, I think Haskell does an excellent job of facilitating composition without parentheses, and thus I'm going to contradict what I said earlier about parens always being necessary. But Haskell also does automatic currying, which even Lisp doesn't do. Without automatic currying, I'm pretty sure my original point still stands.

You are possibly right about indentation errors, but the way I understood it, the Readable plugin does not take away any compositional powers. It's just equivalences:

  f(a b) == (f a b)
  {a f b} == (f a b)

+ some edge cases {a b}=(a b) {a}=(a) {}=() etc

Does the Python community struggle with indentation? I thought it was largely a non-issue.

Indentation is an occasional minor annoyance when copy pasting, but otherwise mostly solved by IDEs. In any case very acceptable given the much increased readability and esthetics. I'm not sure if semantic bugs from mixing tabs and spaces are even possible with modern python parsers.

  if 1:
  <tab>if 0:
  <tab><tab>print(1)
  <spaces*n>print(2)

could print 2 if mixing tabs and spaces were allowed. was it ever?

There was a vertical-tab run in ‘13 that really hurt a lot of us; other than that, the Central Space Bank (at least in the US) has kept things fairly stable. (This is ignoring the doom-and-gloom quantitative-tab-easing conspiracy theory nuts.)

How about the opposite direction? Instead of needing parentheses in a language with infix notation, can parentheses be removed in a language with prefix notation (like Lisp)?

Is elegant composition possible with prefix notation and some whitespace and indentation instead of parentheses everywhere?

I think it might be.

That is exactly is the proposal discussed here.

Reply on news.ycombinator.com