Nim: parser should accept parenthesized (unambiguous) multiline expression

[timotheecour]

this is currently allowed:

proc foo(): bool =
  return (true and
    false and
    false)

this doesn't compile:

proc foo(): bool =
  return (true
    and false
    and false)

This second case is un-ambiguous and arguably easier to read/write/edit than first case, could that be allowed, or is there any fundamental reason it can't be?
(after adaptation from https://scripter.co/notes/nim/#line-continuation)

rationale for being easier to read/write/edit:

here's a common use case:
We can easily read each condition as a single line; it's easier to comment / uncomment

return (x > 0
  ## easy to comment out a condition
  # and score > scoreMin
  and score < scoreMax
  and isOk(y))

EDIT
same comment with functional programming, eg here's an example from https://github.com/nim-lang/Nim/issues/8258

let n = zip(aArray, bArray) -->
  map(f(it[0], it[1])).
  filter(it mod 4 > 1).
  map(it * 2).
  all(it > 4)

would be more readable as:

let n = (zip(aArray, bArray)
   --> map(f(it[0], it[1]))
  .filter(it mod 4 > 1)
  .map(it * 2)
  .all(it > 4))

links

• [EDIT] [Multiline conditions - Nim forum](https://forum.nim-lang.org/t/6899)

[Araq]

Not gonna happen. Newline continuations need to be triggered by a preceding token. Your rationale only covers "editability" btw.

[kaushalmodi]

Surprised to see my notes linked here.. I wished the proposed style (operator at beginning of the line style) worked.. it makes the code much more readable and editable. That style has worked in all the languages I've used till date. Can some brain storming be put into this to see if there's a tiny bit possibility that Nim can do it too?

[kaushalmodi]

Newline continuations need to be triggered by a preceding token.

Can the compiler be made to do a "relaxed search" for token i.e. if it freaks out on not finding a token at end of line, make it look for the token at the beginning of the next uncommented line.. and if still not found, then fail..

[citycide]

This doesn't help if you want to comment the last or first condition since they include parens. I always used this style:

proc foo (): bool =
  return (
    true and
    false and 
    false
  )

[kaushalmodi]

@citycide By putting the operator (and) at the beginning of line, it tremendously improves the code readability.. by glancing a complicated multiline expression, it's easier to figure out where that expression begins and ends as the operators at beginning of line create a neat column.

[kaushalmodi]

Take the more complicated expression from https://scripter.co/notes/nim/#line-continuation as an example (the aligned ands on the left side in the snippet that does not work quick tells that it's a continuation of the expression above).

[citycide]

@kaushalmodi I disagree that it's more readable. When I have a list of conditions like this, I don't much care that the joining _operators_ form a neat column as I'm far more interested in what the _conditions_ are.

[kaushalmodi]

@citycide

This doesn't help if you want to comment the last or first condition since they include parens

That doesn't work for your example too (you cannot just comment out the last condition). And paren by itself on separate lines, for the operator at beginning of line style will give similar results.. just that the first condition cannot be commented out, but the last can.

[citycide]

@kaushalmodi from the OP:

it's easier to comment / uncomment

I was mainly making a point about how this didn't improve editability at all, because you still have a leading or trailing operator anyway. If you want improvement, separate the parens and that's the best you can do.

We can easily read each condition as a single line

It also doesn't necessarily do this. I don't see how starting a line with the operator makes it easier to read the line than ending with the operator.

it's easier to figure out where that expression begins and ends as the operators at beginning of line create a neat column.

And to this point of yours, it's unnecessary if you use the style I posted above — just look for the closing paren with matching indentation.

This just isn't worth complicating the parser in my opinion.

[Bulat-Ziganshin]

I think that parens should have higher priority than indentation and after open paren compiler should just eat everything until closed paren. Indentation rule exists exactly to avoid syntax clutter in form of any parens, and once you have exact delimiters for beginning and end of expression and statement, you can and should ignore indentation.

But it's some ideal, I understand that changing rules and modifying the compiler require time and there are higher-priority topics. Can we just agree that it should be eventually implemented, even if in Nim v3?

[Araq]

Can we just agree that it should be eventually implemented, even if in Nim v3?

We can agree on that there is likely a better design to handle an indentation based syntax (I have a couple of ideas on my own...) and I'm positive to make that a reality for Nim v2 or v3.