Mirror of forum.nim-lang.org

7416 :: Why aren't the built-in math procs (`+`, `-`, `*`, ...) procvars?

• RainbowAsteroids (orginal) [2021-01-23T01:41:27+01:00] view original

  It seems a little weird for Nim to make these procs and then set special rules, preventing you from passing them in as parameters to other procs.

  proc someHigherOrderProc(fn: proc(x, y: int): int) =
    discard
  someHigherOrderProc(`+`)
  Run

  has to become:

  proc someHigherOrderProc(fn: proc(x, y: int): int) =
    discard
  someHigherOrderProc(proc(x, y: int) = x + y)
  Run

  which needlessly makes the code more messy.

---

• Tuatarian (orginal) [2021-01-23T03:15:44+01:00] view original

  I don't have an answer to your question, but use

  import sugar
  
  proc someHigherOrderProc(f: (int, int) -> int) =
    discard
  
  
  someHigherOrderProc((x, y) => x + y)
  Run

  for less mess

---

• shirleyquirk (orginal) [2021-01-23T04:05:07+01:00] view original

  + etc aren't really procs, i mean, in C terms you can't have a function pointer to + unless you go ahead and define an addition function.

  templates are perfect for passing expressions around (the way mapIt, filterIt etc do) that might be a better fit for what you're trying to do, without adding the overhead of a function call

---

• RainbowAsteroids (orginal) [2021-01-23T06:36:46+01:00] view original

  in C terms you can't have a function pointer to +

  I guess that makes sense, and it would definently be a needless performance hit to create a function just for this edge case.

  templates are perfect for passing expressions around

  I'm sorta new to Nim and metaprogramming, so I didn't think about using a template. Here is the code that inspired the question, but I don't really see how I would refactor it to utilize a template.

---

• alexeypetrushin (orginal) [2021-01-23T07:02:34+01:00] view original

  + etc aren't really procs, i mean, in C terms you can't have a function pointer to + unless you go ahead and define an addition function.

  Couldn't they be defined with something like {.inline.} in Nim? So it will be used as a normal proc in Nim but the C code will be generated as a + b?

---

• Araq (orginal) [2021-01-23T07:17:51+01:00] view original

  Couldn't they be defined with something like {.inline.} in Nim?

  The compiler could do things like that, yes. But features start in the state "not implemented" and there are many things left to do that are more important. Esp. since the alternative via templates works really well.

---

• shirleyquirk (orginal) [2021-01-23T21:32:21+01:00] view original

  Couldn't render post #47034.

---

• RainbowAsteroids (orginal) [2021-01-23T23:27:54+01:00] view original

  Thanks showing me how! I'm a bit confused on what {.gensym.} means though. I tried reading the manual section about template hygiene, and I didn't fully comprehend it. Maybe because I don't fully understand templates in general.

---

• shirleyquirk (orginal) [2021-01-24T00:01:29+01:00] view original

  at first approximation templates are like c macros, (without the footguns). they can for sure get complicated, but at a high level, it's copy/paste.

  so without the

  {.gensym.}
  Run

  you get a redefinition error, because you define a proc

  Run

  for addition, then a second proc, also called

  Run

  for subtraction...

  {.gensym.}
  Run

  tells the template to generate a unique symbol each time. "fn_gensym3" or whatever

  another way to do the same thing is to wrap it in a

  Run

  :
  template operation(op:untyped):proc() =
    block:
      proc fn() = discard
      fn
  Run

---