Mirror of forum.nim-lang.org

2988 :: Do notation without parentheses

• bluenote (orginal) [2017-06-05T23:39:02+02:00] view original

  I'm still getting confused about the do notation. In particular I'm surprised that the following gives an error "redefinition of x":

  import future
  
  proc takesFunc(f: () -> void) =
    f()
  
  takesFunc do:
    var x = 1
  
  takesFunc do:
    var x = 1
  Run

  The manual mentions something that do without parenthesis is just a block. I don't understand that, what is the compiler passing to the function in this case?

  Adding some empty parentheses after the do solves the problem, but if the version without the parentheses is not creating an anonymous proc, shouldn't this lead to a more meaningful error? Otherwise finding such a bug is a bit by chance like in my case with the redefinition.

---

• Lando (orginal) [2017-06-06T11:09:34+02:00] view original

  The code tries to pass a parameter with the wrong type to that proc, yes. But the compiler doesn't even get that far: early on, it detects two blocks defining the same variable in the same context, hence the error message. To avoid this, one would have to delay symbol lookup with something like the untyped "type" for template and macro parameters. Not sure whether this even works (or should work) with regular procedures.

---

• bluenote (orginal) [2017-06-06T20:16:19+02:00] view original

  The code tries to pass a parameter with the wrong type to that proc, yes. But the compiler doesn't even get that far:

  I'm not sure about that. So with having just one body or no conflicts you would expect a type error? But this compiles and works just fine:

  import future
  
  proc takesFunc(f: () -> void) =
    echo "running f()"
    f()
    echo "done running f()"
  
  takesFunc do:
    var x = 1
    echo x
  
  takesFunc do:
    var y = 2
    echo y
  Run

  Output:

  
  running f()
  1
  done running f()
  running f()
  2
  done running f()
  Run

---

• LeuGim (orginal) [2017-06-06T23:41:57+02:00] view original

  The error is not related to the coincidence of the variables' names. The error is with the type of what is passed to takesFunc - do w/o parentheses is not taken as a procedure. The last example doesn't compile for me, unless parentheses are added.

---

• bluenote (orginal) [2017-06-07T00:19:09+02:00] view original

  Strange, it does compile for me on devel (just updated to 2b8a1cee8cbeddb3e64193a59a78b5d0f46d2fda but it was the same with an older devel). I only get the coincidental errors.

---

• LeuGim (orginal) [2017-06-07T05:14:14+02:00] view original

  I tested with 0.16.1. With current 0.17.1 indeed the last example compiles, and the first fails with redifinition. So now do means something different, I don't know what. May be a bug, maybe a special case of blocks with no new scope. Otherwise blocks open new scopes, and this for example did compile and still does now:

  block:
    var x = 1
    echo x
  
  block:
    var x = 2
    echo x
  Run

---

• Krux02 (orginal) [2017-06-07T14:56:47+02:00] view original

  There was a breaking change in the do notation that I don't approve personally at all. But I thought it was parsing rules only.

---

• Lando (orginal) [2017-06-07T21:07:49+02:00] view original

  I tested with 0.16.1. With current 0.17.1

  I used 0.17.0 (stable), same behavior. So now we now what Nim does here:

  • do is auto-converted to do ()
  • The following block does not automatically form a scope of its own

  The second point is corroborated by the fact that bluenote's first example does compile when I add explicit block statements to force a scope.

  import future
  
  proc takesFunc(f: () -> void) =
    f()
  
  takesFunc do:
    block:
      var x = 1
  
  takesFunc do:
    block:
      var x = 1
  Run

  And I really don't like that. If it becomes a procedure, making its body a scope would seem more intuitive to me.

  By the way, there seem to be two different ideas of "block" in Nim, an unscoped and a scoped one. See the manual section "Passing a code block to a template". The whole typed vs untyped thing only makes sense when blocks without an explicit block statement are unscoped.

---

• bluenote (orginal) [2017-06-07T22:13:27+02:00] view original

  Most likely this is not really intended. For instance, this now compiles, but produces invalid C code:

  import future
  
  proc takesFunc(f: () -> void) =
    f()
  
  takesFunc do:
    var x = 1
  
  echo x
  Run

  Probably best to track this as an issue: https://github.com/nim-lang/Nim/issues/5963

---