 Recently I wrote a blog post on writing a Boolean expression parser in Rust. Here I'll give a more visual overview of how this whole process works. See that blog post for the full details. First we start with the expression to parse. At this point we lex the expression and build a list of tokens out of it. From this point how the tokens were originally encoded in the source file doesn't matter. Whitespace is entirely removed and different ways to write binary operators like the word or and the pipe symbol are collapsed into the same representation here. We don't try to interpret the tokens here or even validate that the tokens are valid. Next we build an abstract syntax tree or asked. Now instead of having a list of tokens the input will be represented in terms of operators and their relations. Let's see how it works for this example. First we encounter a name literal. We then look ahead to see what the following token is. Since it's a Boolean operator and and you know that this is the start of a Boolean expression we start the AST with the AND operation at the root. Now that we had to look ahead at the first token to determine what to do. This is required whenever we're using infix notation for binary operations. Well something like reverse polish notation would be far better here as it would be unambiguous and wouldn't require any looking ahead. Unfortunately reverse polish notation is just a little too obscure for me to use in this Boolean language. The next token is an exclamation point which just inverts the value of whatever's after it. Let's insert an invert node into the AST. The next token is a bracket so everything up to the matching closing bracket will be inverted. We see a name literal bar followed by a binary operation so we've handled this before. Next we see another invert token. The inversion is followed by yet another name literal. By looking ahead we can see there isn't a binary operation following it so it's just going to be a lone literal. Finally we get to the closing bracket matching the one for earlier. We've finished building our AST. Now let's put our AST to use and see how it evaluates a simple expression. Let's see what happens when there's a single input tag. Foo. We recursively evaluate the AST all the way down to the name literal. This evaluated information then bubbles up to the top giving us the final answer. This expression did not match the input tags. I looked the source code for this system in the description. Thanks for watching.