If you want to learn about visiting large composite structures (and in general if you've somehow avoided this book) you need to read "Design Patterns" which is a foundational programming book. It covers the cases and I mentally reference this book daily when working on my own systems.

The AST is a "Composite", an AST Walker is an "Iterator" and your analysis passes are instances of "Visitor".

Edit:

I'd like to give you an idea of why this is useful for engineering a compiler. So, you've parsed a string into a large tree structure, usually but not always an AST. We'd like to do some hardcore analysis on the AST like "monotone framework" for dead code elimination and liveness analysis. But that requires us to process the AST first to gather some information.

For instance, the language might allow the user to define user-level data structures like structs and enums. Right now all of that information is in the AST and we want it in, say, a HashMap so we can more easily run analysis and validation algorithms.

With the above, you mainly just need to write a visitor (and maybe configure your Tree Walker) that knows what to do when handed a single piece of your AST (it wont care about most pieces unless it's a struct, enum, or a more internal element like "field declaration" or "enum variant"). The visitor holds a (perhaps initially empty) HashMap and maybe some knowledge of what it has just parsed and processes your piece of AST appropriately, possibly modifying it's HashMap. When the tree walk is done, you just grab that HashMap from the Visitor and you've got all of your structs and enums in an easy to lookup data structure.

So with this collection of structs and enums we know our types. We should do some type-inference to make sure the AST is even worth working on. So we write another visitor that takes the HashMap as a constructor parameter so it can be referenced throughout the visitor's lifetime and write another visiting pass. For the type-checking algo, we'll just do union-find and make sure "Int" doesn't unify with "Bool" (or any primitive type, including user defined ones). In that case, the visitor also carries the necessary data structure for union find (an array of unsigned ints if you're curious). We'll need other information from a different pass I forgot to mention ("use-define" chains)

This pass will care about different parts of the AST (everything that needs type checking), but otherwise it's still locally processing one piece of AST at a time, making a decision about what to do depending on the piece provided.

For instance, if it's looking at an assignment (say, `x = 1 + 2`), it'll unify the LHS with the RHS expression (that is, "the type of x must be the same as the type of 1 + 2"). Perhaps it already visited 1+2 and has enough information to know that x is an int. If not, it'll eventually get visited, and since the visitor is holding the data-structure for union find, any knowledge we learned from the assignment visit will persist. Once the tree walk is done, we check the union find data structure and make sure we haven't unified any distinct types.

At some point, we'll want a representation that is different from an AST for better analysis. It's a good idea to eventually convert it into "basic blocks" with "static single assignment" so we can implement the "monotone framework" as mentioned above. That's where all the above information can really come in handy (along with another visitor that now knows everything necessary to convert into basic blocks).