Mirror of forum.nim-lang.org

369 :: kibitzing regrading the passing of an array into a proc/macro with varargs

• micklat (orginal) [2014-02-17T10:52:08+01:00] view original

  Working on the python bindings, I've been repeatedly confounded by the compiler's treatment of macros with varargs. This sort of macro is essential when trying to embed a foreign language into Nimrod in a way that looks natural.

  Assuming the bugs (#913, #935) will eventually get fixed, the remaining issue will be the handling of macro calls such as:

  
  import macros, strutils
  
  macro countArgs(n: int, p: varargs[expr]): stmt =
    echo toStrLit(callsite()), " receives $1 arguments ($2 expected)" % [$len(p), $n.intVal]
    result = newEmptyNode()
  
  countArgs(1, [1,2,3]) # output: receives 3 arguments (1 expected)
  Run

  Currently, countArgs(1, [1,2,3]) is treated the same as countArgs(1,1,2,3), which is as-designed, but inconvenient. It is inconvenient because the two often have different meanings, especially when interfacing with foreign languages, but also, I think, in certain cases of pure nimrod code. Araq seems to agree that it would be better to treat these cases as separate. However, distinguishing between these cases (and treating countArgs(1, [1,2,3])) as a call with 2 rather than 4 arguments) is likely to break existing code.

  I therefore suggest this migration plan towards consistent handling of varargs, and pray that the language's developers, in their great wisdom, should view it with favour:

  • a new kind of varargs will be introduced, with a different syntax. I propose to use the ellipsis:

  
  macro foo(a: int, b: string, args... : openarray[expr])
  Run

  • when a user wants to pass the varargs in a single argument, she would do so explicitly:

  
  let argsArray = [1,2,3]
  bar(42, argsArray...)
  Run

  • the current kind of varargs will be retained for backwards-compatibility, but deprecated and warned against by the compiler.

---

• Araq (orginal) [2014-02-18T01:49:51+01:00] view original

  I don't think ... is necessary. You only need varargs[expr, toValue] with an appropriate toValue operation.

---

• micklat (orginal) [2014-02-18T06:37:52+01:00] view original

  awesome! thanks for the tip!

---

• micklat (orginal) [2014-02-18T06:48:36+01:00] view original

  OK. This method works like a charm for the python bindings. However, in the lua bindings, I have a problem with this approach.

  In python, I have a function toPy that converts different kinds of nimrod objects to python objects. So this function serves as the varargs converter and everything's swell.

  In lua, the corresponding function toLua takes two arguments: the lua interpreter state and the value to be converted. If the macro accepts varargs[expr], it can apply toLua itself to each argument, because the macro has a reference to the lua state.

  I can't specify args: varargs[PLuaRef, toLua] however, because toLua is not a unary function. So, to use this approach, I'd need to abandon support for multiple lua interpreters. This is an option, I suppose, because your suggestion seems to fix a lot of problems with varargs. But I'm not sure I want to do that.

  Any thoughts?

---

• micklat (orginal) [2014-02-18T06:51:23+01:00] view original

  BTW, I found that I can work around most of the problems by pulling the macro arguments out of callsite(). But there's also the question of what the Nimrod language should be like, beyond my desires as a library developer.

---