Mirror of forum.nim-lang.org

12619 :: Spaces around operators matters

• tcheran (orginal) [2024-12-07T12:56:57+01:00] view original

  In this code

  
  let a = 2
  let b = 3
  
  let good = a + b #clean
  let yesbut = a+b #acceptable
  let bad = a +b #ugly but... Nim compiler refuse it -> Error: attempting to call routine 'a', found 'a'
  Run

  I concede that the last assignment is "ugly", but while some other programming languages accept it, for Nim is just wrong. What is the reason? Is it wrong in terms of syntax or in terms of semantics? What the compiler is figuring out there?

  Thank you

---

• morturo (orginal) [2024-12-07T14:31:12+01:00] view original

  a +b looks more like a command call (https://nim-lang.org/docs/macros.html#callsslashexpressions-command-call), you have an ident followed by args. That is what the compiler is telling you.

---

• tcheran (orginal) [2024-12-07T15:06:13+01:00] view original

  Thank you @Morturo

  With some little help from ChatGPT I guess that most likely is related to seeing +b as a unary operator. I was misled by the fact that '+' unary operator has no practical impact... but '-' has, and the parsing rules should be consistent across all possible unary operators. Still the error code "call routine" is not very clear to me.

---

• tcheran (orginal) [2024-12-07T16:45:30+01:00] view original

  No, it makes sense. Once the unary operator is consumed, it just sees the assignment like this:

  
  let bad = a b
  Run

  and it complains I'm trying to run "a" func or proc, i.e. a(b)

---

• stoking (orginal) [2024-12-08T05:28:40+01:00] view original

  The manual alludes to the effect of whitespace on parsing operators and calls: https://nim-lang.org/docs/manual.html#syntax-precedence

---

• JohnAD (orginal) [2024-12-13T21:27:15+01:00] view original

  There is a small part of me that wishes that a future version of Nim demanded spaces for operators.

  So, x = a+b would say Error: undeclared identifier: 'a+b'.

  Why would this be good:

  1. Enforce consistent spacing and, more importantly,
  2. more safely identify multi-character operators.

  And even make way for library support of enclosures. For example, if an operator macro is declared that starts with (, {, or [, then its reverse pairing would activate. Like this silly example:

  
  template `[#`(ablock: untyped) =
    echo "'''text"
    ablock
    echo "'''"
  
  # and here I use it. Notice that there is a space after the # starting this comment.
  
  [#
    echo "foo"
    echo "bar"
  #]
  Run

  This would take Nim's DSL support to whole new levels.

---

• Araq (orginal) [2024-12-13T21:38:47+01:00] view original

  For example, if an operator macro is declared that starts with (, {, or [, then its reverse pairing would activate. Like this silly example: ...

  Interesting but that could be added to the language without your "spaces around operators" requirement.

---

• JohnAD (orginal) [2024-12-13T21:41:06+01:00] view original

  The downside, of supporting enclusures (or anything which would require spaces around ops), is that the spacing is hard on the eyes sometimes. For example:

  
  var a = (1+2)*((3+2)+4)
  Run

  is pretty but

  
  var a = ( 1 + 2 ) * ( ( 3 + 2 ) + 4 )
  Run

  is less pretty.

---

• JohnAD (orginal) [2024-12-13T22:24:15+01:00] view original

  For example, if an operator macro is declared that starts with (, {, or [, then its reverse pairing would activate. Like this silly example: ...

  Interesting but that could be added to the language without your "spaces around operators" requirement.

  I've not been in the nim parser for a long while. So perhaps I am wrong about that.

  If it was added, a question to ponder: should < and > also be allowed to be in enclosures; or would that create too much visual confusion? So, allowing <!% %!> pairing for example? Or <<<< >>>>.

  It would also probably be best to forbid any closures in the opening operator. So, {{{$ $}}} is okay, but {{{$} {$}}} would be a big no-no.

---

• dlesnoff (orginal) [2024-12-17T11:56:34+01:00] view original

  The rule I used in nim/bigints is spacing around operators but not around enclosures.

  I would thus write JohnAD's example as:

  
  var a = (1 + 2) * ((3 + 2) + 4)
  Run

  This middleground between the two options is far more readable to me than the "pretty" proposal that I would not call pretty at all.

  I do not understand: supporting enclosures in template do not require spaces around them. We shall remove from supported enclosures all the delimiters already used by the language just like there is a set of reserved keywords for identifiers.

---

• JohnAD (orginal) [2025-01-04T20:35:04+01:00] view original

  I would thus write JohnAD's example as:

  
  var a = (1 + 2) * ((3 + 2) + 4)
  Run

  That seems reasonable. The only catch is for multi-character enclusures, the (( would require extra spacing as a (( )) enclosure pair could be defined.

  So:

  
  var a = (1 + 2) * ( (3 + 2) + 4)
  Run

---