[flyx86]

Now see, that's much clearer. From the perspective of someone who knows Lisp, perhaps. I find it very confusing. Moreover, you are using an example from a tutorial, which is meant to explain how things work, not to show what the best way to write some macro is.

You can write the same macro with less verbosity:

    macro debug(n: varargs[typed]): typed =
      result = newNimNode(nnkStmtList, n)
      for x in n:
        let xRepr = toStrLit(x)
        result.add(quote do: writeLine(stdout, `xRepr` & ": " & $`x`))

[lispm]

That's not too far away from Lisp. But in Lisp we would be using some quasiquote templates for this simple macro:

    (defmacro debug-it (&body expressions)
      `(progn
         ,@(mapcar (lambda (expression)
                     `(format t "~%~a: ~a" ',expression ,expression))
                   expressions)))

Example:

    CL-USER 8 > (pprint (macroexpand-1 '(debug-it (+ 1 2) (* 3 4))))

    (PROGN
      (FORMAT T "~%~a: ~a" '(+ 1 2) (+ 1 2))
      (FORMAT T "~%~a: ~a" '(* 3 4) (* 3 4)))

    CL-USER 9 > (debug-it (+ 1 2) (* 3 4))

    (+ 1 2): 3
    (* 3 4): 12
    NIL

[qwertyuiop924]

I could have done that, but I couldn't be bothered to look up the interpolation strings for format (yes, we have it), or the one level flatten function, and the splicing unquote is less efficient than cons in this case. But yes, in real code, I'd probably go in that direction.

There is one key difference between my code and yours: in mine, the functions, values, and symbols referenced in the macro are automatically renamed, thus guaranteeing no namespacing conflicts. Due to the way the CL package system works (IIRC), CL provides almost the same guarantees, at least in this case. But it is an important semantic difference.

And it is the Common Lisp. Despite how you may feel, Scheme, Clojure, PicoLisp, NewLisp, Racket, Interlisp, LeLisp, EuLisp, and others are as much a Lisp as CL.

[lispm]

Procedural macros were introduced to Lisp twenty years before CL existed and quasiquotation around ten years before CL existed.

> and the splicing unquote is less efficient than cons in this case

Not sure why that should be the case and why it even matters.

[qwertyuiop924]

True, but as my code aptly demonstrated, procedural macros don't work the same jb all Lisps. Some Lisps don't even have them.

AFAICT, splicing unquote has to traverse the entire result list. Not super relevant in this case.

I don't know why I picked cons, honestly. I guess it just fit ny mental model of what was happening better.

[lispm]

> AFAICT, splicing unquote has to traverse the entire result list. Not super relevant in this case.

Especially since it is usually done once at compile time.

> Some Lisps don't even have them.

Even most Scheme implementations have them.

[qwertyuiop924]

Well, then it's slowing down compilation.

And yes, most schemes have them. I was talking about Picolisp, Newlisp, and Kernel, which don't.

[JadeNB]

> > Now see, that's much clearer.

> From the perspective of someone who knows Lisp, perhaps.

For what it's worth, as a perpetual novice programmer who knows Lisp a little and Nim not at all, I also found qwertyuiop924 (https://news.ycombinator.com/item?id=12617350 )'s example much clearer. (EDIT: Of course it's totally anecdotal, but I thought that it might be worthwhile to have a data point from someone who is not an expert in either language.)

[qwertyuiop924]

You'll find lispm's, from a sibling comment, even clearer:

  (defmacro debug-it (&body expressions)
    `(progn
        ,@(mapcar (lambda (expression)
                    `(format t "~%~a: ~a" ',expression ,expression))
                  expressions)))

That's Common Lisp. I probably could have made mine similarly clean, but I was too lazy to do so :-).

Anyways, hats off to lispm, because he's the one who actually did it.

[qwertyuiop924]

Ah, thanks. I didn't mean to misrepresent Nim, but I don't know the language super well.

It seems Nim has a code templating system, which is nice, but I find a bit more confusing and less pleasant than the Lisp equivalent. As I said before, it just feels clumsy, especially compared to Lisp.