79:T481,Before diving into the details of syntax analysis, let's understand where it fits in the broader query processing pipeline. When a SQL query arrives at the database engine, it undergoes a series of transformations: **The Complete Query Processing Pipeline:** 1. **Query Receipt** — The raw SQL string arrives from a client connection 2. **Lexical Analysis** — The string is broken into meaningful tokens 3. **Syntax Analysis** — Tokens are validated against SQL grammar rules 4. **Semantic Analysis** — Names are resolved and types are verified 5. **Query Rewriting** — The query may be transformed for optimization 6. **Query Optimization** — Multiple execution plans are evaluated 7. **Query Execution** — The optimal plan is executed 8. **Result Return** — Data is returned to the client Syntax analysis encompasses steps 2 and 3 in this pipeline, though some systems combine them into a single parsing phase. The output of syntax analysis is typically a **parse tree** (also called **Abstract Syntax Tree** or AST)—a hierarchical data structure that represents the query's structure in a form suitable for subsequent processing.7a:T6a7,// Simplified Lexer State Machine function nextToken(): skipWhitespaceAndComments() if atEndOfInput(): return Token(EOF) char = peekChar() // Identifiers and Keywords if isLetter(char) or char == '_': word = consumeWhile(isAlphanumeric or '_') if word.toUpperCase() in RESERVED_KEYWORDS: return Token(KEYWORD, word) else: return Token(IDENTIFIER, word) // Numeric Literals if isDigit(char): num = consumeWhile(isDigit) if peekChar() == '.': consume('.') num += '.' + consumeWhile(isDigit) return Token(FLOAT_LITERAL, num) return Token(INTEGER_LITERAL, num) // String Literals if char == "'": consume("'") str = "" while not atEndOfInput(): if peekChar() == "'" and peekAhead(1) == "'": str += "'" consume("''") else if peekChar() == "'": consume("'") return Token(STRING_LITERAL, str) else: str += consumeChar() error("Unterminated string literal") // Operators (with lookahead for multi-char) if char == '<': consume('<') if peekChar() == '=': consume('=') return Token(OPERATOR, "<=") if peekChar() == '>': consume('>') return Token(OPERATOR, "<>") return Token(OPERATOR, "<") // ... similar patterns for other operators // Single-character tokens if char in "(),;": return Token(DELIMITER, consumeChar()) error("Unexpected character: " + char)7b:T5f9,-- Simplified SQL SELECT Statement Grammar (BNF notation) ::= SELECT FROM [WHERE ] [GROUP BY ] [HAVING ] [ORDER BY ] ::= '*' | {',' } ::= [AS ] | '.' '*' ::= [] | ON | '(' ')' [AS ] ::= | ::= | ::= | | | '(' ')' | ::= | AND | OR | NOT | '(' ')' ::= | IS [NOT] NULL | [NOT] IN | [NOT] BETWEEN AND | [NOT] LIKE 7c:T430,Database systems use various parsing algorithms, each with different tradeoffs. Understanding these helps explain why some SQL constructs parse successfully while others cause unexpected errors. **Bottom-Up Parsing (LR Parsing):** Most production database parsers use **LR parsing** or its variants (SLR, LALR). These parsers: - Read tokens left-to-right - Construct the parse tree from leaves up to root - Use a **parse table** generated from the grammar - Handle a broad class of grammars efficiently The most common tool for generating LR parsers is **Yacc** (Yet Another Compiler Compiler) or its GNU equivalent **Bison**. PostgreSQL, MySQL, and many other databases use Bison-generated parsers. **Top-Down Parsing (LL Parsing):** Some databases and SQL parsers use **LL parsing** or recursive descent: - Start from the grammar's start symbol - Recursively expand non-terminals - Match terminals against input tokens - Often hand-written for more control Recursive descent parsers are easier to understand and debug but may struggle with left-recursive grammars.7d:T466,-- Example 1: Missing FROM keyword SELECT employee_name, salary employees WHERE department = 'Sales'; -- PostgreSQL error: -- ERROR: syntax error at or near "employees" -- LINE 1: SELECT employee_name, salary employees WHERE department = 'Sa... -- ^ -- Example 2: Mismatched parentheses SELECT * FROM orders WHERE (status = 'pending' AND amount > 100; -- PostgreSQL error: -- ERROR: syntax error at or near ";" -- LINE 1: ...orders WHERE (status = 'pending' AND amount > 100; -- ^ -- Hint: Missing closing parenthesis -- Example 3: Invalid column list syntax SELECT name,, salary FROM employees; -- PostgreSQL error: -- ERROR: syntax error at or near "," -- LINE 1: SELECT name,, salary FROM employees; -- ^ -- Example 4: String literal issues SELECT * FROM employees WHERE name = 'O'Brien'; -- PostgreSQL error: -- ERROR: syntax error at or near "Brien" -- LINE 1: SELECT * FROM employees WHERE name = 'O'Brien'; -- ^ -- Correct: WHERE name = 'O''Brien'71:{"json":{"id":"seed_2fba8438b5f7f0a02285c5d377f04e04","slug":"parsing-and-validation","category":"Database Management Systems","topic":"Query Processing","title":"Parsing and Validation","description":"Master the critical first stages of query processing: how databases parse SQL statements, validate syntax and semantics, resolve object references, perform type checking, and construct parse trees that drive optimization and execution.","difficulty":"INTERMEDIATE","estimatedMinutes":75,"pages":[{"id":"seed_b6a2eac6d33450d06f8f30b83dec62e9","title":"Syntax Analysis","order":0,"content":[{"id":"opening-hook","title":"The Query's First Test","content":[{"data":{"content":"Every SQL query you write must pass through a gauntlet of validation before a single row of data is ever touched. The database system scrutinizes your query at multiple levels, and the very first checkpoint is **syntax analysis**—the process of ensuring your query is structurally valid according to the rules of the SQL language.\n\nWhen you execute a query like `SELECT name FROM employees WHERE salary > 50000`, the database doesn't immediately start searching through tables. Instead, it first breaks down your query into individual tokens, checks that these tokens are arranged according to SQL's grammar rules, and constructs a structured representation suitable for further processing.\n\nThis seemingly simple step is surprisingly sophisticated. Modern database systems process millions of queries per second, and each one must pass through syntax analysis with microsecond-level efficiency while providing clear, actionable error messages when something goes wrong."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand the complete syntax analysis pipeline: from raw query text to structured parse tree. You'll learn how lexical analysis breaks queries into tokens, how grammar rules define valid SQL structure, how databases detect and report syntax errors with precision, and why this phase is critical for both correctness and performance.","variant":"info"},"type":"callout"}]},{"id":"parsing-pipeline-overview","title":"The Parsing Pipeline Overview","content":[{"data":{"content":"$79"},"type":"text"},{"data":{"height":"200px","mermaidSyntax":"flowchart LR\n A[\"Raw SQL\nQuery String\"] --> B[\"Lexical\nAnalyzer\"]\n B --> C[\"Token\nStream\"]\n C --> D[\"Syntax\nAnalyzer\"]\n D --> E[\"Parse\nTree/AST\"]\n E --> F[\"Semantic\nAnalyzer\"]\n \n style A fill:#e3f2fd,stroke:#1976d2,stroke-width:2px\n style B fill:#fff3e0,stroke:#f57c00,stroke-width:2px\n style C fill:#e8f5e9,stroke:#388e3c,stroke-width:2px\n style D fill:#fff3e0,stroke:#f57c00,stroke-width:2px\n style E fill:#e8f5e9,stroke:#388e3c,stroke-width:2px\n style F fill:#fce4ec,stroke:#c2185b,stroke-width:2px"},"type":"mermaid-excalidraw"},{"data":{"icon":"BookOpen","title":"Historical Context","content":"The parsing techniques used in database systems are direct descendants of compiler technology developed in the 1960s and 1970s. Many database parsers are actually built using the same tools (like yacc/bison and lex/flex) that have been used to build programming language compilers for decades. This shared heritage explains why database professionals often speak the same language as compiler engineers when discussing parsing.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"lexical-analysis","title":"Lexical Analysis: The First Pass","content":[{"data":{"content":"Lexical analysis—also called **tokenization** or **scanning**—is the process of converting a raw character stream into a sequence of **tokens**. Each token represents a meaningful unit in the SQL language: a keyword, an identifier, a literal value, an operator, or punctuation.\n\n**Why Tokenization Matters:**\n\nConsider this SQL query:\n```sql\nSELECT employee_name, salary FROM employees WHERE department_id = 10\n```\n\nTo a human, this is clearly a query that selects employee names and salaries from employees in department 10. But to the database, it initially arrives as a stream of 54 ASCII characters including spaces. The lexer's job is to transform this character stream into structured tokens that subsequent phases can process efficiently.\n\nThe lexer component (also called a **scanner** or **tokenizer**) reads characters left-to-right, identifies token boundaries, classifies each token, and passes the token stream to the parser."},"type":"text"},{"data":{"rows":[["**Keywords**","`SELECT`, `FROM`, `WHERE`, `INSERT`, `UPDATE`","Reserved words with special meaning in SQL syntax"],["**Identifiers**","`employees`, `department_id`, `customer_name`","Names of tables, columns, schemas, aliases, etc."],["**String Literals**","`'John Doe'`, `'New York'`","Quoted character sequences"],["**Numeric Literals**","`42`, `3.14159`, `-100`, `1.5e10`","Integer and floating-point numbers"],["**Operators**","`=`, `<>`, `>=`, `+`, `-`, `*`, `||`","Comparison, arithmetic, and string operators"],["**Delimiters**","`(`, `)`, `,`, `;`","Punctuation that structures the query"],["**Comments**","`-- comment`, `/* block */`","Ignored by parser, used for documentation"],["**Whitespace**","spaces, tabs, newlines","Token separators (usually discarded)"]],"caption":"Token Types in SQL Lexical Analysis","headers":["Token Category","Examples","Description"]},"type":"table"},{"data":{"content":"**Tokenization Example:**\n\nLet's trace how the lexer processes our example query character by character:"},"type":"text"},{"data":{"code":"-- Original Query:\nSELECT employee_name, salary FROM employees WHERE department_id = 10\n\n-- Resulting Token Stream:\nToken 1: KEYWORD \"SELECT\"\nToken 2: IDENTIFIER \"employee_name\"\nToken 3: COMMA \",\"\nToken 4: IDENTIFIER \"salary\"\nToken 5: KEYWORD \"FROM\"\nToken 6: IDENTIFIER \"employees\"\nToken 7: KEYWORD \"WHERE\"\nToken 8: IDENTIFIER \"department_id\"\nToken 9: OPERATOR \"=\"\nToken 10: INTEGER \"10\"\n\n-- Note: Whitespace between tokens is consumed but not emitted\n-- Each token carries:\n-- 1. Token type (KEYWORD, IDENTIFIER, etc.)\n-- 2. Token value (the actual text)\n-- 3. Position information (line, column) for error reporting","fileName":"tokenization-example.sql","showLineNumbers":true},"type":"code"}],"titleType":"number","titleNumber":2},{"id":"lexer-implementation","title":"Lexer Implementation Details","content":[{"data":{"content":"Understanding how lexers actually work reveals important details about SQL parsing behavior. Modern database lexers are typically implemented using one of two approaches:\n\n**1. Hand-Written Lexers:**\nSome databases (notably PostgreSQL) use carefully hand-crafted lexers written in C. These offer maximum control over tokenization behavior and can be highly optimized for specific SQL dialects.\n\n**2. Generated Lexers:**\nOther databases use lexer generators like **Lex** or **Flex** that create lexer code from a declarative specification. This approach is faster to develop and easier to maintain.\n\nRegardless of implementation approach, all lexers must handle several challenging aspects of SQL tokenization:"},"type":"text"},{"data":{"items":["**Keyword Recognition vs Identifiers** — Is `SELECT` a keyword or could it be a table name? Most SQL dialects reserve keywords, but some allow escaping (e.g., `\"SELECT\"` as an identifier in PostgreSQL).","**Case Sensitivity** — SQL keywords are case-insensitive (`SELECT` = `select` = `SeLeCt`), but identifier handling varies by database. MySQL is case-insensitive on Windows by default, case-sensitive on Linux.","**String Literal Handling** — Single quotes delimit strings, but what about embedded quotes? Most SQL uses `''` to escape (`'O''Brien'`), but some databases support backslash escaping.","**Numeric Literal Variations** — The lexer must distinguish integers, decimals, and scientific notation (`42`, `3.14`, `1.5e-10`), plus handle negative signs correctly.","**Multi-Character Operators** — Operators like `<>`, `>=`, `||`, and `::` require lookahead to distinguish from single-character operators.","**Comment Handling** — Both line comments (`--`) and block comments (`/* */`) must be recognized and typically stripped before parsing.","**Unicode Support** — Modern databases must handle Unicode identifiers and string literals, significantly complicating character classification."],"title":{"icon":"Code2","text":"Lexer Implementation Challenges","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"code":"$7a","fileName":"lexer-pseudocode.txt","showLineNumbers":true},"type":"code"},{"data":{"icon":"Zap","title":"Performance Consideration","content":"Production database lexers are heavily optimized. They often use lookup tables for character classification (rather than function calls), buffer tokens to avoid repeated allocation, and minimize branching to improve CPU pipeline efficiency. PostgreSQL's lexer, for instance, can tokenize millions of characters per second.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"grammar-and-parsing","title":"SQL Grammar and Syntax Rules","content":[{"data":{"content":"Once the lexer produces a token stream, the **parser** takes over. The parser's job is to verify that the tokens are arranged according to the **grammar rules** of SQL and to build a parse tree representing the query's structure.\n\n**What is a Grammar?**\n\nA grammar is a formal specification of what constitutes a valid statement in a language. SQL grammars are typically specified using **Backus-Naur Form (BNF)** or a variant like **Extended BNF (EBNF)**. These notations define:\n\n- **Non-terminals** — Abstract syntactic categories (like `` or ``)\n- **Terminals** — Actual tokens from the lexer (like `SELECT` or `IDENTIFIER`)\n- **Production Rules** — Rules showing how non-terminals expand into sequences of terminals and non-terminals\n\nLet's look at a simplified excerpt from an SQL grammar:"},"type":"text"},{"data":{"code":"$7b","fileName":"sql-grammar-bnf.txt","showLineNumbers":true},"type":"code"},{"data":{"content":"**Grammar Complexity:**\n\nThe actual SQL grammar is vastly more complex than this excerpt. The SQL:2016 standard grammar has hundreds of production rules covering:\n\n- All DML statements (SELECT, INSERT, UPDATE, DELETE, MERGE)\n- All DDL statements (CREATE, ALTER, DROP for tables, indexes, views, procedures, etc.)\n- Transaction control (COMMIT, ROLLBACK, SAVEPOINT)\n- Session settings and pragmas\n- Procedural extensions (CASE, IF, LOOP, etc.)\n- Window functions, CTEs, lateral joins, and more\n\nPostgreSQL's `gram.y` file (the grammar specification), for example, is over 15,000 lines of grammar rules. MySQL's grammar is similarly extensive. This complexity is why writing a complete SQL parser from scratch is a multi-month undertaking."},"type":"text"}],"titleType":"number","titleNumber":4},{"id":"parser-types","title":"Parser Types and Algorithms","content":[{"data":{"content":"$7c"},"type":"text"},{"data":{"left":[{"data":{"items":["Handles larger class of grammars","Table-driven, very efficient","Generated from declarative specs","Error recovery can be complex","Used by PostgreSQL, MySQL, SQLite","Industrial strength and well-tested"],"title":{"icon":"CheckCircle","text":"LR Parsing (Bottom-Up)","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["Easier to understand and debug","Hand-written for fine control","Better error messages possible","May need grammar refactoring","Used in some query builders","Flexible for dialect variations"],"title":{"icon":"Code2","text":"LL Parsing (Top-Down)","type":"icon","color":"secondary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"content":"**Parsing Complexity:**\n\nBoth LR and LL parsing run in **O(n)** time where n is the number of tokens. This linear complexity is crucial—imagine if parsing complexity were O(n²) for queries with thousands of tokens. For a SELECT with 500 columns (not unusual in data warehouses), quadratic parsing would be catastrophic.\n\nThe constant factors matter too. LR parsers using optimized table-driven approaches can parse tokens with just a few memory accesses per token. Combined with efficient lexing, modern databases can parse complex queries in microseconds."},"type":"text"},{"data":{"icon":"Info","title":"Parser Generator Tools","content":"Many databases use Bison (or its predecessor Yacc) combined with Flex (or Lex) for lexer generation. This combination has been standard since the 1970s. More modern tools like ANTLR offer similar functionality with better debugging support and multiple target languages. Some newer databases (like CockroachDB) use Go-based parser generators that integrate with their codebase.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"syntax-error-detection","title":"Syntax Error Detection and Reporting","content":[{"data":{"content":"One of the most visible aspects of syntax analysis is **error detection and reporting**. When you write malformed SQL, the parser must:\n\n1. Detect that the query violates grammar rules\n2. Identify the location of the error as precisely as possible\n3. Generate a helpful error message\n4. Optionally, attempt to recover and continue parsing\n\n**Types of Syntax Errors:**"},"type":"text"},{"data":{"rows":[["Missing keyword","`SELECT name employees`","Expected `FROM` after select list"],["Misspelled keyword","`SLECT name FROM employees`","SLECT not recognized as keyword or valid identifier position"],["Missing delimiter","`SELECT name salary FROM employees`","Expected `,` or `FROM` after `name`"],["Unbalanced parentheses","`WHERE (a = 1 AND b = 2`","End of input reached with unclosed parenthesis"],["Unterminated string","`WHERE name = 'John`","End of line/input in string literal"],["Invalid operator","`WHERE salary = = 100`","Unexpected `=` after operator"],["Missing expression","`SELECT FROM employees`","Expected expression in select list"],["Reserved word misuse","`SELECT select FROM table`","Unexpected keyword in identifier position"]],"caption":"Common SQL Syntax Errors","headers":["Error Type","Example","Parser Detection"]},"type":"table"},{"data":{"code":"$7d","fileName":"syntax-errors-examples.sql","showLineNumbers":true},"type":"code"},{"data":{"content":"**Error Message Quality:**\n\nThe quality of syntax error messages varies dramatically between database systems. Good error messages:\n\n- Point to the **exact location** of the error (line and column number)\n- Explain **what was expected** vs. what was found\n- Suggest **possible corrections** when unambiguous\n- Avoid cascading errors (one mistake shouldn't produce 20 error messages)\n\nPostgreSQL is generally praised for its error messages, while some databases produce notoriously cryptic errors. This quality difference stems from how much engineering effort is invested in the parser's error-handling routines."},"type":"text"},{"data":{"icon":"Lightbulb","title":"Debugging Syntax Errors","content":"When facing a cryptic syntax error, try these strategies: (1) Simplify the query by removing clauses until it parses, then add them back one at a time; (2) Check for invisible characters (copy-pasted text sometimes includes zero-width characters); (3) Verify string delimiters and escape sequences; (4) Use a SQL formatter to restructure the query visually.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"parse-tree-construction","title":"Building the Parse Tree","content":[{"data":{"content":"As the parser validates the token stream against grammar rules, it simultaneously constructs a **parse tree** (also called an **Abstract Syntax Tree** or **AST**). This tree is the structured representation of the query that subsequent phases—semantic analysis, optimization, execution—will operate upon.\n\n**Parse Tree Structure:**\n\nThe parse tree mirrors the grammar's hierarchical structure:\n- **Internal nodes** represent grammar non-terminals (like `SELECT_STATEMENT`, `WHERE_CLAUSE`)\n- **Leaf nodes** represent terminals (actual tokens from the query)\n- **Edges** represent the \"contains\" relationship between grammar productions\n\nLet's trace the parse tree for a simple query:"},"type":"text"},{"data":{"code":"-- Query:\nSELECT name, salary FROM employees WHERE department = 'Sales'\n\n-- Simplified Parse Tree Structure:\n\nSelectStatement\n├── SelectList\n│ ├── SelectItem\n│ │ └── ColumnRef: \"name\"\n│ └── SelectItem\n│ └── ColumnRef: \"salary\"\n├── FromClause\n│ └── TableRef: \"employees\"\n└── WhereClause\n └── ComparisonExpr\n ├── Operator: \"=\"\n ├── Left: ColumnRef \"department\"\n └── Right: StringLiteral \"'Sales'\"","fileName":"parse-tree-example.sql","showLineNumbers":true},"type":"code"},{"data":{"height":"350px","mermaidSyntax":"graph TD\n A[SelectStatement] --> B[SelectList]\n A --> C[FromClause]\n A --> D[WhereClause]\n B --> E[SelectItem: name]\n B --> F[SelectItem: salary]\n C --> G[TableRef: employees]\n D --> H[ComparisonExpr]\n H --> I[\"ColumnRef: department\"]\n H --> J[\"Op: =\"]\n H --> K[\"Literal: 'Sales'\"]\n \n style A fill:#e3f2fd,stroke:#1976d2,stroke-width:2px\n style B fill:#fff3e0,stroke:#f57c00,stroke-width:2px\n style C fill:#fff3e0,stroke:#f57c00,stroke-width:2px\n style D fill:#fff3e0,stroke:#f57c00,stroke-width:2px"},"type":"mermaid-excalidraw"},{"data":{"content":"**AST vs. Concrete Syntax Tree:**\n\nDatabase systems typically build an **Abstract Syntax Tree (AST)** rather than a full **Concrete Syntax Tree (CST)**. The difference:\n\n- **CST** includes every token, including punctuation, parentheses, and formatting\n- **AST** retains only semantically significant elements, discarding syntactic sugar\n\nFor example, the parentheses in `WHERE (a = 1)` might appear in a CST but would be omitted from an AST since they don't affect meaning—the grouping is already captured in the tree structure.\n\n**AST Node Types:**\n\nTypical database AST nodes include:\n- `SelectStmt`, `InsertStmt`, `UpdateStmt`, `DeleteStmt` — Statement types\n- `ResTarget` — Items in a SELECT list\n- `RangeVar` — Table references\n- `JoinExpr` — Join expressions with conditions\n- `BoolExpr` — AND/OR/NOT combinations\n- `OpExpr` — Operator expressions (comparisons, arithmetic)\n- `Const` — Literal values\n- `ColumnRef` — Column references\n- `FuncCall` — Function invocations\n- `SubLink` — Subqueries"},"type":"text"}],"titleType":"number","titleNumber":7},{"id":"summary","title":"Summary: Syntax Analysis Foundation","content":[{"data":{"content":"Syntax analysis forms the critical first validation layer for every SQL query. Let's consolidate what we've learned:"},"type":"text"},{"data":{"type":"ordered","items":["**Lexical analysis** breaks raw SQL text into tokens—keywords, identifiers, literals, operators, and delimiters—creating structured input for parsing.","**Grammar rules** formally define valid SQL structure using BNF notation, specifying how tokens can be legally arranged.","**Parsers** (typically LR/LALR using tools like Bison) validate token sequences against grammar rules in O(n) time.","**Syntax errors** are detected when token sequences violate grammar rules, with error quality depending on parser implementation.","**Parse trees (ASTs)** are the output of syntax analysis—hierarchical structures representing query logic for subsequent processing.","**Performance matters** — parsing must be fast (microseconds) since every query passes through this phase."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's Next:**\n\nSyntax analysis ensures your query is structurally valid SQL, but it says nothing about whether the tables, columns, and operations you've specified actually make sense. That's the job of **semantic analysis**, which we'll explore in the next page. There, we'll see how databases resolve names to actual database objects, verify type compatibility, and prepare the query for optimization."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand the complete syntax analysis pipeline: from raw SQL text through lexical analysis, token generation, grammar-based parsing, error detection, and parse tree construction. This foundation enables the deeper semantic checks covered next.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_203cd82f3bb54e16d1cfa0167270a810","title":"Semantic Analysis","order":1,"content":null,"isLocked":true},{"id":"seed_a397997ed9c1c470dff1f38005420fce","title":"Name Resolution","order":2,"content":null,"isLocked":true},{"id":"seed_167d0dab0433abb255f462b4c8861238","title":"Type Checking","order":3,"content":null,"isLocked":true},{"id":"seed_e246e9a450b356ff65b40611c029ab87","title":"Parse Tree","order":4,"content":null,"isLocked":true}]}}