5 ms·
Parens are anything but superfluous. Substituting whitespace for parens is a net loss IMO because indentation errors become semantic rather than merely unaesth
by dreamcompiler 7y ago
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.
- traderjane 7y agoDoes the Python community struggle with indentation? I thought it was largely a non-issue.
- singularity2001 7y agoIndentation 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?
- thechao 7y agoThere 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.)
- singularity2001 7y agoYou 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
- breck 7y ago> 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/ 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.
- singularity2001 7y ago>> 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)
- breck 7y agoSorry, 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.
- TeMPOraL 7y agoAssigning 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.
- breck 7y agoAgreed. Almost all the code I write is prefix notation. I do like to explore infix languages (and even postfix /concatenative languages as well).
- dreamcompiler 7y agoFWIW, 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.
- hn_dead_app 7y agoHow 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.
- singularity2001 7y agoThat is exactly is the proposal discussed here.