Mirror of forum.nim-lang.org

4524 :: Best practices of meta-programming

• novikov (orginal) [2019-01-03T11:26:44+01:00] view original

  What are the best practices of meta-programming? And what are anti-patterns?

  So far I could find:

  • provide debugging info
  • check AST node type before doing anything with it

---

• Araq (orginal) [2019-01-03T18:49:55+01:00] view original

  You probably said it already, but this idiom served me well:

  macro m() =
    ...
    when defined(nimDumpM):
      echo repr result
  Run

  Other random notes:

  • don't turn Nim into C with converter toBool(x: int): bool
  • Don't overload macros/templates that use untyped parameters.
  • Write the macro transformation carefully. Ensure that the lineinfo in the nodes remains useful.
  • Check the error messages that resulted from misuse of your macro.

---

• gemath (orginal) [2019-01-04T08:52:20+01:00] view original

  These practices helped me, don't know whether they are "best" :-)

  Keep it obvious: inner templates are probably more readable than constructing and assembling AST nodes "by hand":

  macro m(...): untyped =
    template tpl(...) =
      # people see what is built here
    
    # other logic
    
    result = getAst(tpl(...))
  Run

  Prefer procs to sub-macros where possible: in case a piece of meta-code should be reuseable, a proc accepting NimNode arguments can do most things a macro can, plus it

  • should be more compile-time efficient
  • behaves less surprisingly to novice programmers

---

• Libman (orginal) [2019-01-05T06:44:17+01:00] view original

  Meta-programming has trade-offs, which is why languages like Go chose to avoid it. The main ones are:

  • Added Compile Time. Nim is already implicitly taking a stand that you shouldn't do your compiling on a low-end machine, and I believe that we are on the right side of history. (This is compared to for example Go. C/C++ compiling is much slower even without meta-programming, due to bad and/or ancient language design.) Developer machines are becoming faster, CPU power is becoming cheaper, and you can also compile via a remote server / "the cloud". BUT there's still room for improvement, like caching. Some code generating tasks need only be done once.
  • Code Reading Difficulty. Again, Nim's philosophy already sides with tool-aided developer productivity over the hypothetical need to ever read the code in Notepad / paper / cave wall. And, again, we're on the right side of history - this makes Nim better than the less powerful alternatives. BUT we still need better tooling. Your IDE must be able to tell you what anything and everything is, including compile time code transformations (with specific limits).

---

• arso96 (orginal) [2019-01-10T21:37:19+01:00] view original

  http://patshaughnessy.net/2011/12/20/learning-from-the-masters-part-2-three-metaprogramming-best-practices was just reading this article about metaprogramming, i think it's pretty inetesting, hope this might help regards

---

• zevv (orginal) [2019-01-11T15:58:23+01:00] view original

  Write the macro transformation carefully. Ensure that the lineinfo in the nodes remains useful.

  Where can I find any examples of this?

---