Are you talking about using Lisp macros to generate C/C++/documentation? I'm not sure how Lisp macros would be better than static metadata files being operated on by some high level scripting language.

The author created a DSL which generates code. Macros are another way to do that.

Or nim, which is even more powerful

First, can you talk a little about how Nim's macro system is more-powerful than Lisp's? That seems like a fairly broad claim, and unless it allows you to influence the compiler at compile time (and maybe even then), I am curious how that works out.

Second, one of the biggest issues with lisp is that macros end up sort of slow, especially when you're using them + lists to replicate ADTs with pattern matching (versus, say, ML, which can do very fast dispatch based on types). Doesn't Nim fall into that same trap?

It can do absolutely everything lisp macros can do, with more flexible input syntax, and zero runtime overhead, while being both strongly typed and giving the macro body access to the types

(PS: Lisp fanboys downvoting this, how about attempting to make a counterargument instead of just hitting the downvote button?)

Lisp macros have runtime overhead? I don't think reader macros or compile macros have any runtime overhead unless you add it yourself.

More flexible input syntax than a programmable reader? Data like sexps and edn is pretty flexible to begin with, but a lot of lisps have fully programmable readers for arbitrary syntax. Some lisps even support grammar dialects to switch out of sexps entirely (such as racket).

Nim macros operate directly on the ast while providing flexible user friendly (read: not sexp) calling syntax.

Everything is fully typed, and the types are available to the macro expansion.

Absurdly powerful things have been done, for instance https://github.com/krux02/opengl-sandbox which crosscompiles nim to GPU shaders.

It's like you didn't read the previous poster: They're claiming lisp macros can work BEFORE the compiler generates an AST.

Ok this is nice but you this would be rougly the same in Lisp, apart from AST constructors ("newIdentNode()",...), which would simply be backquote/unquote. Plus you have to write enumInfo[0], enumInfo[1] instead of pattern matching.

And if I wanted to make 'for' into a valid variable name, or change the tokens for specifying numbers, for example, how would I go about doing that?

Easily. The macro gets handed the ast of the input. It can interpret it however it wants. There are no reserved words or anything like that. Much of nim is implemented as macros, just like most lisps

The lisp macros run before the AST exists.

Does Nim really have read time macros? (https://letoverlambda.com/index.cl/guest/chap4.html)

I don't understand what you mean by more flexible input syntax? Lisp hardly has any syntax to begin with; it's one of my favorite things about the language. (If that's a problem for a particular usecase, the aforementioned read time macros can change that.)

Regarding giving the macro body access to the types, that's because Nim is statically typed. I'm sure Lisp would do the same if it were as well, but it's (mostly) dynamic and that's life.

Your definition of flexible must differ from mine. The fact that you mentioned an AST as a plus and macros w/ runtime overhead tells me you don’t understand Lisp.

Lisp macros operate on a representation of the AST.

By overhead I mean the nim compiler can generate direct specific instatiations at compile time instead of doing runtime based duck-typing as in lisp.

Like, you can have a macro that generates a different expansion based on the type of arguments passed, if you structure the macro that way.

The macro can also take entire code blocks as arguments of course, so you can implement general purpose control structures that are first class citizens.

Here's an example: https://peterme.net/cross-platform-guis-and-nim-macros.html

> Lisp macros operate on a representation of the AST.

The representation of the AST is the AST in Lisp (Scheme has syntax objects).

> By overhead I mean the nim compiler can generate direct specific instatiations at compile time instead of doing runtime based duck-typing as in lisp.

SBCL has `deftransform`, which allows macro expansions to benefits from static type analysis.