Mirror of forum.nim-lang.org

8610 :: dot-like operations and calls

• markspanbroek (orginal) [2021-11-11T10:10:40+01:00] view original

  I'm struggling with the new dot-like operators in Nim 1.6. I wrote a library called questionable that makes heavy use of the .? operator. You can for instance call a function on an optional value like this:

  option.?foo(bar)
  Run

  I match these using a macro with the following signature:

  macro `.?`*(option: typed, call: untyped{nkCall}): untyped
  Run

  When I enable the nimPreviewDotLikeOps option, this macro will no longer be called because instead of parsing the expression above as an infix operation on an identifier and a call, it now parses it as a call to an infix operator:

  
  Before:           |   After:
                    |
  Infix             |   Call
    Ident ".?"      |     Infix
    Ident "option"  |       Ident ".?"
    Call            |       Ident "option"
      Ident "foo"   |       Ident "foo"
      Ident "bar"   |     Ident "bar"
  Run

  I'm at a loss how to write a macro that matches a call and its arguments with the new dot-like operators. Any help would be greatly appreciated :)

---

• PMunch (orginal) [2021-11-11T10:22:08+01:00] view original

  Haven't tested this, but writing a macro with the name .? which returns a closure that takes the same arguments as foo but does the option branching first should work.

---

• Araq (orginal) [2021-11-11T11:15:14+01:00] view original

  The best option seems to be to rename the operator to ?., sorry.

---

• markspanbroek (orginal) [2021-11-11T11:15:58+01:00] view original

  I tried this, but ran into two problems:

  1. I don't know how many arguments foo has, because I no longer see the call in the macro, only the identifier of the proc.
  2. I'm not able to differentiate between a function call option.?foo() or a field access option.?foo, so I don't know when to return a closure and when to simply return the field value.

---

• markspanbroek (orginal) [2021-11-11T11:39:52+01:00] view original

  Thanks, I can do that. In previous versions I actually called the operator ?., but I moved away from it because of its low precedence. It does mean that users of the library will need to use extra parentheses in some places. For example, expressions such as if a =? b.?c: would become if a=? (b.?c):.

---

• DeletedUser (orginal) [2021-11-11T17:48:36+01:00] view original

  Given that the distinction for "dot-like operators" are made, would it make sense for a.?b(c) to transform into:

  
  Infix
    Ident ".?"
    Ident "a"
    Ident "b"
    Ident "c"
  Run

  or maybe a new DotLike node kind instead of Infix? Or just transform Call expressions with dotlike infix expression call addresses into the old AST.

  In case you are wondering, Infix expressions with more than 2 arguments are already possible by doing 1 + 2: 3.

---

• markspanbroek (orginal) [2021-11-15T10:40:53+01:00] view original

  If you were to ask me, I would prefer either the DotLike or the old Call options, because they're explicit. The Infix with more arguments would also work for me.

  But I have no insight into how the parser works for the dot-like operators, and what is achievable without too much hassle.

---

• dwin (orginal) [2021-11-17T10:48:47+01:00] view original

  The dot like operator RFC included a proposal for a .?() operator too, which I think would be helpful for this case. Don't think it has been implemented.

---

• markspanbroek (orginal) [2021-11-17T12:04:05+01:00] view original

  Interesting, I didn't see the RFC before. The .?() operator would indeed solve my problem.

  By the way: I tried the workaround with the () operator, but I ran into the problem that I cannot differentiate between a function call option.?foo() or a field access option.?foo, and therefore do not know whether to return something that is callable with the () operator, or a simple field value.

---