You have multiple ways to print the macros either as AST tree or even Nim code that can be copy-pasted to replace the macro:

- dumpTree

- lisprRepr

- treeRepr

- toStrLit

This means that for debugging you can generate your code. Replace the macro by regular code temporarily and understand what's wrong and then fix the macros.

I don't think I have a single library without macro but I try to keep them as reasonable as you can. But sometimes you need to give a Python feel (for example to provide a Numpy interface for a multidimensional array library) or you have to do code transformation (implementing async or multithreading as a library or autovectorizing high-performance computing code or implementing a GPU or Audio DSL) and there is no way around macros.

I have written a lot of metaprogramming myself, like 5/10 of my repos are macro libraries. And I share your concern. Even the manual advices people to use the least "powerful" tool for the job. These are proc/func<template<macro.

Macros are prefered for creating dsl like https://github.com/treeform/fidget or https://github.com/pragmagic/karax

Otherwise the advice is to use them when they "pull their weight". The reason is they're a lot harder to write and even "design" them right (how they function, what code they write, etc) takes a lot of effort. And in most cases the simpler "tools" will fit your needs.

You generally want to use the simplest tool for the job first. Most of the time generics and templates really are as much as you need since Nim's generics are structurally typed and templates allow a lot of metaprogramming without getting into AST trees.

My experience debugging complex compile time transformations is pretty positive thanks to the tools available to manipulate and debug the syntax trees. For example you can `echo node.repr` to display the code it represents at any point, and going the other way you can pass code to `dumpAstGen` to display the code that will generate the AST tree and so on.

This also has the benefit of letting you quickly understand how the trees are structured by trying different bits of code, or for passing DSL syntax fragments to see the parsed tree structure for your macro to consume.

The main important thing is that stack traces at compile time get you to the place where the error is happening. How hard that is to debug depends on how complex your tree manipulation is, and how you are doing that manipulation.

For example if you're just got a load of `quote` statements that interpolate variables and you're chucking these together, the trace will usually lead to the start of the `quote` block, so if you've got a long `quote` block then you have to kind of find the error in that, but it's not too bad since the error messages are pretty precise and the language is strongly typed.

For direct AST manipulation, the error will point to the place where the error is triggered, so for example if you add a bunch of statements in a node, the error may be the place that node is added to it's parent to be 'connected' to the program as a whole. Or, if it's an attempt at a duplicate variable declaration it will point directly to the place where you're creating the `ident` that represents the variable in your macro, so that's pretty nice.

In short, yes it is more work, but it generally makes sense, is type safe, and we have tools that mean fixing stuff is often some `echo` statements to look at generated code.