course-definition.yml

slug: "interpreter"
name: "Build your own Interpreter"
short_name: "Interpreter"
release_status: "beta"

description_md: |-
  This challenge follows the book [Crafting Interpreters](https://craftinginterpreters.com/) by Robert Nystrom.

  In this challenge you'll build an interpreter for [Lox](https://craftinginterpreters.com/the-lox-language.html), a simple scripting
  language. Along the way, you'll learn about tokenization, ASTs, tree-walk interpreters and more.

  Before starting this challenge, make sure you've read the "Welcome" part of the book that contains these chapters:

  - [Introduction](https://craftinginterpreters.com/introduction.html) (chapter 1)
  - [A Map of the Territory](https://craftinginterpreters.com/a-map-of-the-territory.html) (chapter 2)
  - [The Lox Language](https://craftinginterpreters.com/the-lox-language.html) (chapter 3)

  These chapters don't involve writing code, so they won't be covered in this challenge. This challenge will start
  from chapter 4, [Scanning](https://craftinginterpreters.com/scanning.html).

short_description_md: |-
  Learn about tokenization, ASTs, tree-walk interpreters and more.

completion_percentage: 15

languages:
  - slug: "c"
  - slug: "cpp"
  - slug: "gleam"
  - slug: "go"
  - slug: "java"
  - slug: "kotlin"
  - slug: "ocaml"
  - slug: "python"
  - slug: "rust"
  - slug: "javascript"
  - slug: "swift"
    release_status: "alpha"
    alpha_tester_usernames: ["JWShroyer"]
  - slug: "zig"

marketing:
  difficulty: hard
  sample_extension_idea_title: "Control flow"
  sample_extension_idea_description: "An interpreter that can handle control flow statements like if/else"
  testimonials:
    - author_name: "Ananthalakshmi Sankar"
      author_description: "Automation Engineer at Apple"
      author_avatar: "https://codecrafters.io/images/external/testimonials/oxta.jpeg"
      link: "https://github.com/anu294"
      text: "There are few sites I like as much that have a step by step guide. The real-time feedback is so good, it's creepy!"

    - author_name: "Patrick Burris"
      author_description: "Senior Software Developer, CenturyLink"
      author_avatar: "https://codecrafters.io/images/external/testimonials/patrick-burris.jpeg"
      link: "https://github.com/Jumballaya"
      text: |-
        I think the instant feedback right there in the git push is really cool.
        Didn't even know that was possible!

extensions:
  - slug: "parsing-expressions"
    name: "Parsing Expressions"
    description_markdown: |
      This extension covers chapters 5 & 6 of the book ([Representing Code](https://craftinginterpreters.com/representing-code.html) & [Parsing Expressions](https://craftinginterpreters.com/parsing-expressions.html)).

      In this extension, you'll add the ability to parse expressions.

  - slug: "evaluating-expressions"
    name: "Evaluating Expressions"
    description_markdown: |
      This extension covers chapters 7 of the book ([Evaluating Expressions](https://craftinginterpreters.com/evaluating-expressions.html)).

      In this extension, you'll add the ability to evaluate expressions.

  - slug: "statements-and-state"
    name: "Statements & State"
    description_markdown: |
      This extension covers chapters 8 of the book ([Statements & State](https://craftinginterpreters.com/statements-and-state.html)).

      In this extension, you'll add the ability to add internal state to your interpreter & produce output.

  - slug: "control-flow"
    name: "Control Flow"
    description_markdown: |
      This extension covers chapters 9 of the book ([Control Flow](https://craftinginterpreters.com/control-flow.html)).

      In this extension, you'll add the ability to handle control flow statements like `if/else`, `while` & `for`.

stages:
  - slug: "ry8"
    name: "Scanning: Empty file"
    difficulty: very_easy
    description_md: |-
      Before starting this stage, make sure you've read the "Welcome" section of the book that contains these chapters:

      - [Introduction](https://craftinginterpreters.com/introduction.html) (chapter 1)
      - [A Map of the Territory](https://craftinginterpreters.com/a-map-of-the-territory.html) (chapter 2)
      - [The Lox Language](https://craftinginterpreters.com/the-lox-language.html) (chapter 3)

      These chapters don't involve writing code, so they won't be covered in this challenge. This challenge will start
      from chapter 4, [Scanning](https://craftinginterpreters.com/scanning.html).

      ---

      In this stage, you'll implement basic support for the `tokenize` command.

      ### The `tokenize` command

      The `tokenize` command tokenizes a Lox program and prints the tokens to stdout. We'll use this for testing
      all stages in the [Scanning](https://craftinginterpreters.com/scanning.html) chapter.

      If there's a file named `test.lox` with the following contents:

      ```
      var language = "lox";
      ```

      The `tokenize` command will return the following:

      ```
      $ ./your_program.sh tokenize test.lox
      VAR var null
      IDENTIFIER language null
      EQUAL = null
      STRING "lox" lox
      SEMICOLON ; null
      EOF  null
      ```

      This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/tree/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/scanning).

      Each line corresponds to a token in the file (Image from [Section 4.2: Lexemes & Tokens](https://craftinginterpreters.com/scanning.html#lexemes-and-tokens)):

      ![img](https://craftinginterpreters.com/image/scanning/lexemes.png)

      This is the format for each line:

      ```
      <token_type> <lexeme> <literal>
      ```

      - `<token_type>`: The type of the token.
        - Examples: `VAR`, `IDENTIFIER`, `STRING`, `EOF` etc.
      - `<lexeme>`: The actual sequence of characters that formed the token.
        - Examples: `var`, `breakfast`, `"bagels"` etc.
        - For an `EOF` token, the lexeme is an empty string.
      - `<literal>`: The literal value of the token.
        - For most tokens this is `null`.
        - For `STRING`/`NUMBER` tokens, it holds the value of the string/number.

      The `EOF` token is a special token that represents the end of the file. All calls to `tokenize` will include an `EOF` token at the end.

      ### Tests

      The tester will write an empty file to `test.lox`. It'll then run your program like this:

      ```
      $ ./your_program.sh tokenize test.lox
      EOF  null
      ```

      Since the file is empty, only one token is expected in the output: `EOF`. The tester will verify that `EOF<space><space>null` is printed to stdout.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/tree/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/scanning)
      - There are two spaces between `EOF` and `null`. This is because the `<lexeme>` part is an empty string for the `EOF` token.
    marketing_md: |-
      In this stage, you'll implement basic support for the `tokenize` command which we'll use in all stages that are part of the [Scanning](https://craftinginterpreters.com/scanning.html) chapter.

  - slug: "ol4"
    name: "Scanning: Parentheses"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for scanning parentheses.

      ### Book reference

      The code for this stage is implemented in [Section 4.5: Recognizing Lexemes](https://craftinginterpreters.com/scanning.html#recognizing-lexemes).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain parentheses.

      For example, if `test.lox` contains the following:

      ```
      (()
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh tokenize test.lox
      LEFT_PAREN ( null
      LEFT_PAREN ( null
      RIGHT_PAREN ) null
      EOF  null
      ```

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/tree/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/scanning)
      - When scanning for tokens, it's valid to have "unbalanced" parentheses. When we get to parsing expressions in later stages, these cases will be highlighted as errors.
    marketing_md: |-
      In this stage, you'll implement support for scanning parentheses.

  - slug: "oe8"
    name: "Scanning: Braces"
    difficulty: easy
    description_md: |-
      In this stage, you'll add support for scanning braces.

      ### Book reference

      The code for this stage is implemented in [Section 4.5: Recognizing Lexemes](https://craftinginterpreters.com/scanning.html#recognizing-lexemes).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain braces combined with parentheses.

      For example, if `test.lox` contains the following:

      ```{{=<~ ~>=}}
      {{}}
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh tokenize test.lox
      LEFT_BRACE { null
      LEFT_BRACE { null
      RIGHT_BRACE } null
      RIGHT_BRACE } null
      EOF  null
      ```

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/tree/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/scanning)
      - When scanning for tokens, it's valid to have "unbalanced" braces. When we get to parsing expressions in later stages, these cases will be highlighted as errors.
    marketing_md: |-
      In this stage, you'll implement support for scanning braces.

  - slug: "xc5"
    name: "Scanning: Other single-character tokens"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for scanning other single-character tokens, namely `,`, `.`, `-`, `+`, `;` and `*`.
      `/` is not covered here, it's covered in later stages.

      ### Book reference

      The code for this stage is implemented in [Section 4.5: Recognizing Lexemes](https://craftinginterpreters.com/scanning.html#recognizing-lexemes).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain parentheses, braces combined with all the new single-character tokens.

      For example, if `test.lox` contains the following:

      ```
      ({*.,+*})
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh tokenize test.lox
      LEFT_PAREN ( null
      LEFT_BRACE { null
      STAR * null
      DOT . null
      COMMA , null
      PLUS + null
      STAR * null
      RIGHT_BRACE } null
      RIGHT_PAREN ) null
      EOF  null
      ```

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/tree/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/scanning)
      - When scanning for tokens, it's valid to have "unbalanced" parentheses or braces. When we get to parsing expressions in later stages, these cases will be highlighted as errors.
    marketing_md: |-
      In this stage, you'll implement support for scanning other single-character tokens.

  - slug: "ea6"
    name: "Scanning: Lexical errors"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for reporting errors when scanning invalid tokens like `$`, `#`, etc.

      ### Book reference

      The code for this stage is implemented in [Section 4.5.1: Lexical Errors](https://craftinginterpreters.com/scanning.html#lexical-errors).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain unknown tokens mixed with other previously introduced token types.

      For example, if `test.lox` contains the following:

      ```
      ,.$(#
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh tokenize test.lox
      [line 1] Error: Unexpected character: $
      [line 1] Error: Unexpected character: #
      COMMA , null
      DOT . null
      LEFT_PAREN ( null
      EOF  null
      ```

      Errors should be printed to the stderr stream, starting with the `[line N]` prefix. If lexical errors were present,
      your program must exit with exit code 65.

      The tester will assert that:

      - The stderr stream contains one line for each lexical error (if present)
        - Each line must match the format `[line N] Error: Unexpected character: <character>`
      - The stdout stream contains one line for each valid token (even if other lexical errors are present)
      - Your program exits with exit code 65 if lexical errors are present, and exit code 0 if not

      Since we haven't introduced the newline character yet, all errors will start with `[line 1]`. We'll get to multi-line errors in later stages.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/tree/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/scanning)
      - Since stdout and stderr are separate streams, the relative order of errors vs. valid tokens doesn't matter. You're free to print
        errors first, errors last, or errors interleaved with valid tokens.
      - Only lines that start with `[line N]` are considered errors, so you can still print other lines to stderr for debugging purposes.
      - When scanning for tokens, it's valid to have "unbalanced" parentheses or braces. When we get to parsing expressions in later stages, these cases will be highlighted as errors.
    marketing_md: |-
      In this stage, you'll implement support for scanning lexical errors.

  - slug: "mp7"
    name: "Scanning: Assignment & equality Operators"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for scanning assignment & equality operators.

      ### Book reference

      The code for this stage is implemented in [Section 4.5.2: Operators](https://craftinginterpreters.com/scanning.html#operators).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain equality & assignment operators mixed with previously introduced tokens.

      For example, if `test.lox` contains the following:

      ```
      ={===}
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh tokenize test.lox
      EQUAL = null
      LEFT_BRACE { null
      EQUAL_EQUAL == null
      EQUAL = null
      RIGHT_BRACE } null
      EOF  null
      ```

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/tree/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/scanning)
      - When scanning for tokens, it's valid to have "unbalanced" parentheses or braces. When we get to parsing expressions in later stages, these cases will be highlighted as errors.
    marketing_md: |-
      In this stage, you'll implement support for scanning the assignment & equality operators.

  - slug: "bu3"
    name: "Scanning: Negation & inequality operators"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for scanning negation & inequality operators.

      ### Book reference

      The code for this stage is implemented in [Section 4.5.2: Operators](https://craftinginterpreters.com/scanning.html#operators).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain inequality & negation operators mixed with previously introduced tokens.

      For example, if `test.lox` contains the following:

      ```
      !!===
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh tokenize test.lox
      BANG ! null
      BANG_EQUAL != null
      EQUAL_EQUAL == null
      EOF  null
      ```

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/tree/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/scanning)
      - When scanning for tokens, it's valid to have "unbalanced" parentheses or braces. When we get to parsing expressions in later stages, these cases will be highlighted as errors.
    marketing_md: |-
      In this stage, you'll implement support for scanning negation & inequality operators.

  - slug: "et2"
    name: "Scanning: Relational operators"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for scanning relational operators, which are: `<`, `>`, `<=`, `>=`.

      ### Book reference

      The code for this stage is implemented in [Section 4.5.2: Operators](https://craftinginterpreters.com/scanning.html#operators).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain relational operators mixed with previously introduced tokens.

      For example, if `test.lox` contains the following:

      ```
      <<=>>=
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh tokenize test.lox
      LESS < null
      LESS_EQUAL <= null
      GREATER > null
      GREATER_EQUAL >= null
      EOF  null
      ```

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/tree/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/scanning)
      - When scanning for tokens, it's valid to have "unbalanced" parentheses or braces. When we get to parsing expressions in later stages, these cases will be highlighted as errors.
    marketing_md: |-
      In this stage, you'll implement support for scanning relational operators.

  - slug: "ml2"
    name: "Scanning: Division operator & comments"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for scanning the division operator & comments.
      Comments start with `//`, and the division operator is `/`.

      ### Book reference

      The code for this stage is implemented in [Section 4.6: Longer Lexemes](https://craftinginterpreters.com/scanning.html#longer-lexemes).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain `/` & `//` mixed with previously introduced tokens.

      For example, if `test.lox` contains the following:

      ```
      ()// Comment
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh tokenize test.lox
      LEFT_PAREN ( null
      RIGHT_PAREN ) null
      EOF  null
      ```

      Similarly, if `test.lox` contains the following:

      ```
      /()
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh tokenize test.lox
      SLASH / null
      LEFT_PAREN ( null
      RIGHT_PAREN ) null
      EOF  null
      ```

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/tree/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/scanning)
      - There's no token type for comments, your scanner just needs to ignore any characters after `//`.
      - When scanning for tokens, it's valid to have "unbalanced" parentheses or braces. When we get to parsing expressions in later stages, these cases will be highlighted as errors.
    marketing_md: |-
      In this stage, you'll implement support for scanning the division operator & comments.

  - slug: "er2"
    name: "Scanning: Whitespace"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for scanning whitespace characters (tabs, spaces and newlines).

      ### Book reference

      The code for this stage is implemented in [Section 4.6: Longer Lexemes](https://craftinginterpreters.com/scanning.html#longer-lexemes).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain whitespaces (tabs, spaces and newlines) mixed with previously introduced tokens.

      For example, if `test.lox` contains the following:

      ```
      (<|TAB|>
      <|SPACE|>)
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh tokenize test.lox
      LEFT_PAREN ( null
      RIGHT_PAREN ) null
      EOF  null
      ```

      The tester will assert that the stdout of your program matches the format above.

      Note that the tab, space and newline characters are ignored, so they don't appear as tokens in the output.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/tree/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/scanning)
      - In the logs, the spaces will be replaced with `<|SPACE|>` and tabs will be replaced with `<|TAB|>` for readability. The `test.lox` file will contain actual space/tab characters.
      - When scanning for tokens, it's valid to have "unbalanced" parentheses or braces. When we get to parsing expressions in later stages, these cases will be highlighted as errors.
    marketing_md: |-
      In this stage, you'll implement support for scanning whitespace characters.

  - slug: "tz7"
    name: "Scanning: Multi-line errors"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for scanning lexical errors, which span multiple lines.

      ### Book reference

      The code for this stage is implemented in [Section 4.5.1: Lexical Errors](https://craftinginterpreters.com/scanning.html#lexical-errors).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain lexical errors spanning multiple lines.

      For example, if `test.lox` contains the following:

      ```
      #<|SPACE|>(
      )<|TAB|>@
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh tokenize test.lox
      [line 1] Error: Unexpected character: #
      [line 2] Error: Unexpected character: @
      LEFT_PAREN ( null
      RIGHT_PAREN ) null
      EOF  null
      ```

      Errors should be printed to the stderr stream, starting with the `[line N]` prefix. If lexical errors were present,
      your program must exit with exit code 65.

      The tester will assert that:

      - The stderr stream contains one line for each lexical error (if present)
        - Each line must match the format `[line N] Error: Unexpected character: <character>`
      - The stdout stream contains one line for each valid token (even if other lexical errors are present)
      - Your program exits with exit code 65 if lexical errors are present, and exit code 0 if not

      Line numbers should start at 1.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/tree/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/scanning)
      - Since stdout and stderr are separate streams, the relative order of errors vs. valid tokens doesn't matter. You're free to print
        errors first, errors last, or errors interleaved with valid tokens.
      - Only lines that start with `[line N]` are considered errors, so you can still print other lines to stderr for debugging purposes.
      - When scanning for tokens, it's valid to have "unbalanced" parentheses or braces. When we get to parsing expressions in later stages, these cases will be highlighted as errors.
    marketing_md: |-
      In this stage, you'll implement support for scanning multi-line errors.

  - slug: "ue7"
    name: "Scanning: String literals"
    difficulty: hard
    description_md: |-
      In this stage, you'll add support for scanning string literals.

      ### Book reference

      The code for this stage is implemented in [Section 4.6.1: String literals](https://craftinginterpreters.com/scanning.html#string-literals).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain string literals inside double quotes, mixed with previously introduced tokens.

      For example, if `test.lox` contains the following:

      ```
      "foo baz"
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh tokenize test.lox
      STRING "foo baz" foo baz
      EOF  null
      ```

      The tester will assert that the stdout of your program matches the format above.

      As mentioned in the book, the [format for printing out tokens](https://craftinginterpreters.com/scanning.html#location-information) is `<TOKEN_TYPE> <LEXEME> <LITERAL>`. Up until now,
      the `<LITERAL>` field was always `null`. For strings, the `<LITERAL>` field will contain the string's contents.

      If a string is unterminated, a lexical error should be raised.

      For example, if `test.lox` contains the following:

      ```
      "bar
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh tokenize test.lox
      [line 1] Error: Unterminated string.
      EOF  null
      ```

      The tester will assert that an error is raised, and that the error string matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/tree/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/scanning)
      - The `<LEXEME>` field will contain the string's contents including quotes, since it represents the actual characters that matched the token. The `<LITERAL>` field will
        contain the string's contents without quotes, since it represents the string's value.
      - Lox doesn't support escape sequences within strings, so you can't include a `"` inside a string.
      - When scanning for tokens, it's valid to have "unbalanced" parentheses or braces. When we get to parsing expressions in later stages, these cases will be highlighted as errors.
    marketing_md: |-
      In this stage, you'll implement support for scanning string literals.

  - slug: "kj0"
    name: "Scanning: Number literals"
    difficulty: hard
    description_md: |-
      In this stage, you'll add support for scanning number literals.

      ### Book reference

      The code for this stage is implemented in [Section 4.6.2: Number literals](https://craftinginterpreters.com/scanning.html#number-literals).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain number literals mixed with previously introduced tokens.

      For example, if `test.lox` contains the following:

      ```
      42
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh tokenize test.lox
      NUMBER 42 42.0
      EOF  null
      ```

      Just like strings, number literals have a "literal value" attached. Note that the literal value for an integer is represented as "42.0" (with a decimal point). This
      matches the [book's format](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/scanning/numbers.lox).

      You'll also need to handle numbers with a decimal point, for example if `test.lox` contains the following:

      ```
      1234.1234
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh tokenize test.lox
      NUMBER 1234.1234 1234.1234
      EOF  null
      ```

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/scanning/numbers.lox)
      - Although the `<LITERAL>` field for an integer is represented as "42.0" (with a decimal point), the `<LEXEME>` field will contain the integer's value without the decimal point since
        it represents the actual characters that matched the token.
      - When scanning for tokens, it's valid to have "unbalanced" parentheses or braces. When we get to parsing expressions in later stages, these cases will be highlighted as errors.
    marketing_md: |-
      In this stage, you'll implement support for scanning number literals.

  - slug: "ey7"
    name: "Scanning: Identifiers"
    difficulty: hard
    description_md: |-
      In this stage, you'll add support for scanning identifiers.

      ### Book reference

      The code for this stage is implemented in [Section 4.7: Reserved Words and Identifiers](https://craftinginterpreters.com/scanning.html#reserved-words-and-identifiers).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain identifiers mixed with previously introduced tokens.

      For example, if `test.lox` contains the following:

      ```
      foo bar _hello
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh tokenize test.lox
      IDENTIFIER foo null
      IDENTIFIER bar null
      IDENTIFIER _hello null
      EOF  null
      ```

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/tree/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/scanning)
      - When scanning for tokens, it's valid to have "unbalanced" parentheses or braces. When we get to parsing expressions in later stages, these cases will be highlighted as errors.
    marketing_md: |-
      In this stage, you'll implement support for scanning identifiers.

  - slug: "pq5"
    name: "Scanning: Reserved words"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for scanning reserved words, which are: `and`, `class`, `else`, `false`, `for`, `fun`, `if`, `nil`, `or`, `print`, `return`, `super`, `this`, `true`, `var`, `while`.

      ### Book reference

      The code for this stage is implemented in [Section 4.7: Reserved Words and Identifiers](https://craftinginterpreters.com/scanning.html#reserved-words-and-identifiers).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain reserved words mixed with other previously introduced token types.

      For example, if `test.lox` contains the following:

      ```
      and
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh tokenize test.lox
      AND and null
      EOF  null
      ```

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/tree/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/scanning)
      - When scanning for tokens, it's valid to have "unbalanced" parentheses or braces. When we get to parsing expressions in later stages, these cases will be highlighted as errors.
    marketing_md: |-
      In this stage, you'll implement support for scanning reserved words.

  - slug: "sc2"
    primary_extension_slug: "parsing-expressions"
    name: "Booleans & Nil"
    difficulty: hard
    description_md: |-
      In this stage you'll implement support for the `parse` command and handle parsing `true`, `false`, and `nil` literals.

      ### Book reference

      Before starting this stage, make sure you've read the [Representing Code](https://craftinginterpreters.com/representing-code.html) chapter (chapter 5). The
      code covered in that chapter (`AstPrinter`) will be required to generate the output tested in this stage.

      The code for this stage is implemented in [Section 6.2: Recursive Descent Parsing](https://craftinginterpreters.com/parsing-expressions.html#recursive-descent-parsing).

      ### The `parse` command

      In the previous stages, the tester used the `tokenize` command to test your scanner implementation. In this extension, the tester will need to test
      your parser implementation, so it'll use a different command instead: `parse`.

      The `parse` command accepts a path to a file (`test.lox` for example) and prints out the AST representation of the file to stdout.

      For example, if `test.lox` contains the following:

      ```
      2 + 3
      ```

      The `parse` command will return the following:

      ```
      $ ./your_program.sh parse test.lox
      (+ 2.0 3.0)
      ```

      This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/expressions/parse.lox).

      For the same file, here's what the output from `tokenize` would've been:

      ```
      $ ./your_program.sh tokenize test.lox
      NUMBER 2 2.0
      PLUS + null
      NUMBER 3 3.0
      EOF  null
      ```

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain the boolean values `true` & `false`, and the `nil` literal.

      For example, if `test.lox` contains the following:

      ```
      true
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh parse test.lox
      true
      ```

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/expressions/parse.lox)
      <!-- TODO: Clarify how `nil` must be printed: `nil`/`null`? -->
    marketing_md: |-
      In this stage, you'll implement support for parsing binary values and the nil literal.

  - slug: "ra8"
    primary_extension_slug: "parsing-expressions"
    name: "Number literals"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for parsing number literals.

      ### Book reference

      The code for this stage is implemented in [Section 6.2: Recursive Descent Parsing](https://craftinginterpreters.com/parsing-expressions.html#recursive-descent-parsing).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain number literals, we include both integers and floats.

      For example, if `test.lox` contains the following:

      ```
      42.47
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh parse test.lox
      42.47
      ```

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/expressions/parse.lox)
    marketing_md: |-
      In this stage, you'll implement support for parsing number literals.

  - slug: "th5"
    primary_extension_slug: "parsing-expressions"
    name: "String literals"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for parsing string literals.

      ### Book reference

      The code for this stage is implemented in [Section 6.2: Recursive Descent Parsing](https://craftinginterpreters.com/parsing-expressions.html#recursive-descent-parsing).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain string literals, it can contain whitespaces, and numbers too, but everything is inside double quotes.

      For example, if `test.lox` contains the following:

      ```
      "hello"
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh parse test.lox
      hello
      ```

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/expressions/parse.lox)
    marketing_md: |-
      In this stage, you'll implement support for parsing string literals.

  - slug: "xe6"
    primary_extension_slug: "parsing-expressions"
    name: "Parentheses"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for parsing parentheses.

      ### Book reference

      The code for this stage is implemented in [Section 6.2: Recursive Descent Parsing](https://craftinginterpreters.com/parsing-expressions.html#recursive-descent-parsing).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain parentheses, combined with number literals, string literals and booleans.

      For example, if `test.lox` contains the following:

      ```
      ("foo")
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh parse test.lox
      (group foo)
      ```

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/expressions/parse.lox)
      - Errors for unclosed parenthese are not checked in this stage, they'll be checked in later stages.
    marketing_md: |-
      In this stage, you'll implement support for parsing parentheses.

  - slug: "mq1"
    primary_extension_slug: "parsing-expressions"
    name: "Unary Operators"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for parsing the negation operator (`-`) & the logical not operator (`!`).

      ### Book reference

      The code for this stage is implemented in [Section 6.2: Recursive Descent Parsing](https://craftinginterpreters.com/parsing-expressions.html#recursive-descent-parsing).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain unary operators, combined with previously introduced tokens.

      For example, if `test.lox` contains the following:

      ```
      !true
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh parse test.lox
      (! true)
      ```

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/expressions/parse.lox)
    marketing_md: |-
      In this stage, you'll implement support for parsing unary operators `!` and `-`.

  - slug: "wa9"
    primary_extension_slug: "parsing-expressions"
    name: "Arithmetic operators (1/2)"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for parsing the multiplication operator (`*`) & the division operator (`/`).

      ### Book reference

      The code for this stage is implemented in [Section 6.2: Recursive Descent Parsing](https://craftinginterpreters.com/parsing-expressions.html#recursive-descent-parsing).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain multiplicative algebraic operators, combined with previously introduced tokens.

      For example, if `test.lox` contains the following:

      ```
      16 * 38 / 58
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh parse test.lox
      (/ (* 16.0 38.0) 58.0)
      ```

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/expressions/parse.lox)
    marketing_md: |-
      In this stage, you'll implement support for parsing multiplicative algebraic operators `*` and `/`.

  - slug: "yf2"
    primary_extension_slug: "parsing-expressions"
    name: "Arithmetic operators (2/2)"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for parsing the addition operator (`+`) & the subtraction operator (`-`).

      ### Book reference

      The code for this stage is implemented in [Section 6.2: Recursive Descent Parsing](https://craftinginterpreters.com/parsing-expressions.html#recursive-descent-parsing).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain additive algebraic operators, combined with previously introduced tokens.

      For example, if `test.lox` contains the following:

      ```
      52 + 80 - 94
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh parse test.lox
      (- (+ 52.0 80.0) 94.0)
      ```

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/expressions/parse.lox)
    marketing_md: |-
      In this stage, you'll implement support for parsing additive algebraic operators `+` and `-`.

  - slug: "uh4"
    primary_extension_slug: "parsing-expressions"
    name: "Comparison operators"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for parsing comparison operators: `>`, `<`, `>=` & `<=`.

      ### Book reference

      The code for this stage is implemented in [Section 6.2: Recursive Descent Parsing](https://craftinginterpreters.com/parsing-expressions.html#recursive-descent-parsing).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain comparison operators, combined with previously introduced tokens.

      For example, if `test.lox` contains the following:

      ```
      83 < 99 < 115
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh parse test.lox
      (< (< 83.0 99.0) 115.0)
      ```

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/expressions/parse.lox)
    marketing_md: |-
      In this stage, you'll implement support for parsing comparison operators `>`, `<`, `>=` & `<=`.

  - slug: "ht8"
    primary_extension_slug: "parsing-expressions"
    name: "Equality operators"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for parsing equality operators: `==` & `!=`.

      ### Book reference

      The code for this stage is implemented in [Section 6.2: Recursive Descent Parsing](https://craftinginterpreters.com/parsing-expressions.html#recursive-descent-parsing).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain comparison operators, combined with previously introduced tokens.

      For example, if `test.lox` contains the following:

      ```
      "baz" == "baz"
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh parse test.lox
      (== baz baz)
      ```

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/expressions/parse.lox)
    marketing_md: |-
      In this stage, you'll implement support for parsing equality operators `==` & `!=`.

  - slug: "wz8"
    primary_extension_slug: "parsing-expressions"
    name: "Syntactic errors"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for handling syntax errors in expressions.

      ### Book reference

      The code for this stage is implemented in [Section 6.3: Syntax Errors](https://craftinginterpreters.com/parsing-expressions.html#syntax-errors).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain syntax errors.

      For example, if `test.lox` contains the following:

      ```
      (72 +)
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh parse test.lox
      [line 1] Error at ')': Expect expression.
      ```

      The tester will assert that the exit code is 65.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/expressions/parse.lox)
      - The tester won't check the exact error message in this stage, it will only check that the program exits with code 65.
    marketing_md: |-
      In this stage, you'll implement support for handling syntax errors in expressions.

  - slug: "iz6"
    primary_extension_slug: "evaluating-expressions"
    name: "Literals: Booleans & Nil"
    difficulty: hard
    description_md: |-
      In this stage you'll implement support for the `evaluate` command and handle evaluating the `true`, `false`, and `nil` literals.

      ### Book reference

      The code for this stage is implemented in [Section 7.2.1: Evaluating Literals](https://craftinginterpreters.com/evaluating-expressions.html#evaluating-literals).

      ### The `evaluate` command

      In the previous stages, the tester used the `parse` command to test your parser implementation. In this extension, the tester will need to test
      your evaluator implementation, so it'll use a different command instead: `evaluate`.

      The `evaluate` command accepts a path to a file (`test.lox` for example) and prints out the result of evaluating the file to stdout.

      For example, if `test.lox` contains the following:

      ```
      2 + 3
      ```

      The `evaluate` command will return the following:

      ```
      $ ./your_program.sh evaluate test.lox
      5
      ```

      This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/expressions/evaluate.lox).

      For the same file, here's what the output from `parse` would've been:

      ```
      $ ./your_program.sh parse test.lox
      (+ 2.0 3.0)
      ```

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain the boolean values `true` & `false`, and the `nil` literal.

      For example, if `test.lox` contains the following:

      ```
      true
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh evaluate test.lox
      true
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      | Input | Expected output |
      | :---: | :-------------: |
      | `true` | `true` |
      | `false` | `false` |
      | `nil` | `nil` |

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/expressions/evaluate.lox)
      - For the `nil` literal, the tester will check that the program prints `nil`.
    marketing_md: |-
      In this stage, you'll implement support for evaluating binary values and the nil literal.

  - slug: "lv1"
    primary_extension_slug: "evaluating-expressions"
    name: "Literals: Strings & Numbers"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for evaluating number and string literals.

      ### Book reference

      The code for this stage is implemented in [Section 7.2.1: Evaluating Literals](https://craftinginterpreters.com/evaluating-expressions.html#evaluating-literals).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain number literals and string literals.

      For example, if `test.lox` contains the following:

      ```
      "hello world!"
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh evaluate test.lox
      hello world!
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      | Input | Expected output |
      | :---: | :-------------: |
      | `"hello world!"` | `hello world!` |
      | `10.40` | `10.4` |
      | `10` | `10` |

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/expressions/evaluate.lox)
      - For the string literals, the tester will check that the program prints the string without quotes.
      - For the number literals, the tester will check that the program prints the number with the minimum number of decimal places without losing precision. (For example, 10.40 should be printed as 10.4).
    marketing_md: |-
      In this stage, you'll implement support for evaluating number and string literals.

  - slug: "oq9"
    primary_extension_slug: "evaluating-expressions"
    name: "Parentheses"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for evaluating expressions inside parentheses.

      ### Book reference

      The code for this stage is implemented in [Section 7.2.2: Evaluating parentheses](https://craftinginterpreters.com/evaluating-expressions.html#evaluating-parentheses).

      ### Tests

      The tester will test your program using a `test.lox` file that contains an expression with parentheses.

      For example, if `test.lox` contains the following:

      ```
      ("hello world!")
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh evaluate test.lox
      hello world!
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      | Input | Expected output |
      | :---: | :-------------: |
      | `("hello world!")` | `hello world!` |
      | `(true)` | `true` |
      | `(10.40)` | `10.4` |
      | `((false))` | `false` |

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/expressions/evaluate.lox)
      - String literals & number literals must be formatted using the same rules as the previous stage.
    marketing_md: |-
      In this stage, you'll implement support for evaluating expressions inside parentheses.

  - slug: "dc1"
    primary_extension_slug: "evaluating-expressions"
    name: "Unary Operators: Negation & Not"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for evaluating unary operators `-` and `!`.

      ### Book reference

      The code for this stage is implemented in [Section 7.2.3: Evaluating unary expressions](https://craftinginterpreters.com/evaluating-expressions.html#evaluating-unary-expressions).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain expressions with unary operators.

      For example, if `test.lox` contains the following:

      ```
      -(73)
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh evaluate test.lox
      -73
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      | Input | Expected output |
      | :---: | :-------------: |
      | `-73` | `-73` |
      | `!true` | `false` |
      | `!10.40` | `false` |
      | `!((false))` | `true` |

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/expressions/evaluate.lox)
      - For truthyness and falsyness, we will follow the convention introduced in the book, where `false` and `nil` are falsy, and everything else is truthy.
    marketing_md: |-
      In this stage, you'll implement support for evaluating unary operators `-` and `!`.

  - slug: "bp3"
    primary_extension_slug: "evaluating-expressions"
    name: "Arithmetic Operators (1/2)"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for evaluating binary operators `*` and `/`.

      ### Book reference

      The code for this stage is implemented in [Section 7.2.5: Evaluating binary operators](https://craftinginterpreters.com/evaluating-expressions.html#evaluating-binary-operators).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain expressions with the arithmetic operators `*` and `/`.

      For example, if `test.lox` contains the following:

      ```
      (18 * 3 / (3 * 6))
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh evaluate test.lox
      3
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      | Input | Expected output |
      | :---: | :-------------: |
      | `42 / 5` | `8.4` |
      | `18 * 3 / (3 * 6)` | `3` |
      | `(10.40 * 2) / 2` | `10.4` |

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/expressions/evaluate.lox)
      - In this stage, you can assume we will not test for error cases. Runtime errors will be introduced in later stages. For now, all arithmetic operations will involve only two numbers.
    marketing_md: |-
      In this stage, you'll implement support for evaluating binary operators `*` and `/`.

  - slug: "jy2"
    primary_extension_slug: "evaluating-expressions"
    name: "Arithmetic Operators (2/2)"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for evaluating binary operators `+` and `-`.

      ### Book reference

      The code for this stage is implemented in [Section 7.2.5: Evaluating binary operators](https://craftinginterpreters.com/evaluating-expressions.html#evaluating-binary-operators).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain expressions with the arithmetic operators `+` and `-`.

      For example, if `test.lox` contains the following:

      ```
      20 + 74 - (-(14 - 33))
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh evaluate test.lox
      75
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      | Input | Expected output |
      | :---: | :-------------: |
      | `70 - 65` | `5` |
      | `69 - 93` | `-24` |
      | `10.40 - 2` | `8.4` |
      | `23 + 28 - (-(61 - 99))` | `13` |

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/expressions/evaluate.lox)
      - In this stage, you can assume we will not test for error cases. Runtime errors will be introduced in later stages. For now, all arithmetic operations will involve only two numbers.
    marketing_md: |-
      In this stage, you'll implement support for evaluating binary operators `+` and `-`.

  - slug: "jx8"
    primary_extension_slug: "evaluating-expressions"
    name: "String Concatenation"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for overloading the `+` operator. When the `+` operator is applied to two strings, it should concatenate them.

      ### Book reference

      The code for this stage is implemented in [Section 7.2.5: Evaluating binary operators](https://craftinginterpreters.com/evaluating-expressions.html#evaluating-binary-operators).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain expressions with the operator `+`.

      For example, if `test.lox` contains the following:

      ```
      "hello" + " world!"
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh evaluate test.lox
      hello world!
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      | Input | Expected output |
      | :---: | :-------------: |
      | `"hello" + " world!"` | `hello world!` |
      | `"42" + "24"` | `4224` |
      | `"foo" + "bar"` | `foobar` |

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/expressions/evaluate.lox)
      - In this stage, you can assume we will not test for error cases. Runtime errors will be introduced in later stages. For now, we will only pass 2 strings to the `+` operator in this stage.
    marketing_md: |-
      In this stage, you'll implement support for overloading the `+` operator. When the `+` operator is applied to two strings, it should concatenate them.

  - slug: "et4"
    primary_extension_slug: "evaluating-expressions"
    name: "Relational Operators"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for evaluating relational operators `>`, `<`, `>=` & `<=`.

      ### Book reference

      The code for this stage is implemented in [Section 7.2.5: Evaluating binary operators](https://craftinginterpreters.com/evaluating-expressions.html#evaluating-binary-operators).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain expressions with the relational operators `>`, `<`, `>=` & `<=`.

      For example, if `test.lox` contains the following:

      ```
      10 > 5
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh evaluate test.lox
      true
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      | Input | Expected output |
      | :---: | :-------------: |
      | `57 > -65` | `true` |
      | `11 >= 11` | `true` |
      | `(54 - 67) >= -(114 / 57 + 11)` | `true` |

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/expressions/evaluate.lox)
      - In this stage, you can assume we will not test for error cases. Runtime errors will be introduced in later stages. For now, all relational operations will involve only two numbers.
    marketing_md: |-
      In this stage, you'll implement support for evaluating relational operators `>`, `<`, `>=` & `<=`.

  - slug: "hw7"
    primary_extension_slug: "evaluating-expressions"
    name: "Equality Operators"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for evaluating equality operators `==` and `!=`.

      ### Book reference

      The code for this stage is implemented in [Section 7.2.5: Evaluating binary operators](https://craftinginterpreters.com/evaluating-expressions.html#evaluating-binary-operators).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain expressions with the equality operators `==` and `!=`.

      For example, if `test.lox` contains the following:

      ```
      156 == (89 + 67)
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh evaluate test.lox
      true
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      | Input | Expected output |
      | :---: | :-------------: |
      | `"hello" == "world"` | `false` |
      | `"foo" != "bar"` | `true` |
      | `"foo" == "foo"` | `true` |
      | `61 == "61"` | `false` |

      The tester will assert that the stdout of your program matches the format above.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/expressions/evaluate.lox)
      - In this stage, you can assume we will not test for error cases. Runtime errors will be introduced in later stages. For now, all equality operations will involve only two numbers or two strings.
    marketing_md: |-
      In this stage, you'll implement support for evaluating equality operators `==` and `!=`.

  - slug: "gj9"
    primary_extension_slug: "evaluating-expressions"
    name: "Runtime Errors: Unary Operators"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for handling runtime errors while evaluating the unary operator `-`.

      ### Book reference

      The code for this stage is implemented in [Section 7.3: Runtime Errors](https://craftinginterpreters.com/evaluating-expressions.html#runtime-errors).

      ### Tests

      The tester will test your program using a `test.lox` file that contains an expression with the unary operator `-`. This expression
      will contain a usage of the `-` operator that should throw a runtime error.

      The unary operator `-` will throw a runtime error if the operand is not a number.

      For example, if `test.lox` contains the following:

      ```
      -"hello world!"
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh evaluate test.lox
      Operand must be a number.
      [line 1]
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      | Input | Expected output |
      | :---: | :-------------: |
      | `-"foo"` | `Operand must be a number.` |
      | `-true` | `Operand must be a number.` |
      | `-("foo" + "bar")` | `Operand must be a number.` |
      | `-false` | `Operand must be a number. `|

      The tester will assert that the exit code is 70, signifying a runtime error. Note that this is different from the expected exit code for a syntax error, which is 65.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/expressions/evaluate.lox)
    marketing_md: |-
      In this stage, you'll implement support for handling runtime errors while evaluating the unary operator `-`.

  - slug: "yu6"
    primary_extension_slug: "evaluating-expressions"
    name: "Runtime Errors: Binary Operators (1/2)"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for handling runtime errors while evaluating the binary operators `*` & `/`.

      ### Book reference

      The code for this stage is implemented in [Section 7.3: Runtime Errors](https://craftinginterpreters.com/evaluating-expressions.html#runtime-errors).

      ### Tests

      The tester will test your program using a `test.lox` file that contains an expression with the binary operators `*` or `/`. This expression
      will contain a usage of the `*` or `/` operator that should throw a runtime error.

      The binary operators `*` & `/` will throw a runtime error if the operands are not both numbers.

      For example, if `test.lox` contains the following:

      ```
      "foo" / 42
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh evaluate test.lox
      Operands must be numbers.
      [line 1]
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      | Input | Expected output |
      | :---: | :-------------: |
      | `"foo" * 42` | `Operands must be numbers.` |
      | `true / 2` | `Operands must be numbers.` |
      | `("foo" * "bar")` | `Operands must be numbers.` |
      | `false / true` | `Operands must be numbers. `|

      The tester will assert that the exit code is 70, signifying a runtime error. Note that this is different from the expected exit code for a syntax error, which is 65.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/expressions/evaluate.lox)
    marketing_md: |-
      In this stage, you'll implement support for handling runtime errors while evaluating the binary operators `*` & `/`.

  - slug: "cq1"
    primary_extension_slug: "evaluating-expressions"
    name: "Runtime Errors: Binary Operators (2/2)"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for handling runtime errors while evaluating the binary operators `+` & `-`.

      ### Book reference

      The code for this stage is implemented in [Section 7.3: Runtime Errors](https://craftinginterpreters.com/evaluating-expressions.html#runtime-errors).

      ### Tests

      The tester will test your program using a `test.lox` file that contains an expression with the binary operators `+` or `-`. This expression
      will contain usages of the `+` or `-` operator that should throw a runtime error.

      The binary operators `+` & `-` will throw a runtime error if the operands are not both numbers or both strings.

      For example, if `test.lox` contains the following:

      ```
      17 + "bar"
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh evaluate test.lox
      Operands must be two numbers or two strings.
      [line 1]
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      | Input | Expected output |
      | :---: | :-------------: |
      | `"foo" + true` | `Operands must be numbers.` |
      | `42 - true` | `Operands must be numbers.` |
      | `true + false` | `Operands must be numbers.` |
      | `"foo" - "bar"` | `Operands must be numbers. `|

      The tester will assert that the exit code is 70, signifying a runtime error. Note that this is different from the expected exit code for a syntax error, which is 65.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/expressions/evaluate.lox)
    marketing_md: |-
      In this stage, you'll implement support for handling runtime errors while evaluating the binary operators `+` & `-`.

  - slug: "ib5"
    primary_extension_slug: "evaluating-expressions"
    name: "Runtime Errors: Relational Operators"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for handling runtime errors while evaluating the relational operators `>`, `<`, `>=` & `<=`.

      ### Book reference

      The code for this stage is implemented in [Section 7.3: Runtime Errors](https://craftinginterpreters.com/evaluating-expressions.html#runtime-errors).

      ### Tests

      The tester will test your program using a `test.lox` file that contains an expression with the relational operator `>`, `<`, `>=` or `<=`. This expression
      will contain a usage of the relational operator that should throw a runtime error.

      The relational operators `>`, `<`, `>=` & `<=` will throw a runtime error if the operands are not numbers.

      For example, if `test.lox` contains the following:

      ```
      17 > "bar"
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh evaluate test.lox
      Operands must be numbers.
      [line 1]
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      | Input | Expected output |
      | :---: | :-------------: |
      | `"foo" < false` | `Operands must be numbers.` |
      | `true < 2` | `Operands must be numbers.` |
      | `("foo" + "bar") < 42` | `Operands must be numbers.` |
      | `false > true` | `Operands must be numbers. `|

      The tester will assert that the exit code is 70, signifying a runtime error. Note that this is different from the expected exit code for a syntax error, which is 65.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/expressions/evaluate.lox)
    marketing_md: |-
      In this stage, you'll implement support for handling runtime errors while evaluating the relational operators `>`, `<`, `>=` & `<=`.

  - slug: "xy1"
    primary_extension_slug: "statements-and-state"
    name: "Print: Generate output"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for generating output using the `print` statement. For this, you'll need to add support for the `print` statement in your AST generator, parser & interpreter.

      ### Book reference

      The code for this stage is implemented in [Section 8.1: Statements](https://craftinginterpreters.com/statements-and-state.html#statements).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain the `print` statement.

      For example, if `test.lox` contains the following

      ```
      print "Hello, World!";
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh run test.lox
      Hello, World!
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      | Input | Expected output |
      | :---: | :-------------: |
      | `print "Hello, World!";` | `Hello, World!` |
      | `print 42;` | `42` |
      | `print true;` | `true` |
      | `print 12 + 24;` | `36` |

      The tester will assert that the stdout of your program matches the format above, and that the exit code is 0.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/string/literals.lox)
    marketing_md: |-
      In this stage, you'll add support for generating output using the `print` statement.

  - slug: "oe4"
    primary_extension_slug: "statements-and-state"
    name: "Print: Multiple statements"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for handling multiple statements in a single `program`. From here on, we will create test programs that span across multiple statements.

      ### Book reference

      The code for this stage is implemented in [Section 8.1: Statements](https://craftinginterpreters.com/statements-and-state.html#statements).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain multiple statements.

      For example, if `test.lox` contains the following

      ```
      print "Hello, World!";
      print 42;
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh run test.lox
      Hello, World!
      42
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      Test Case 1:

      Input:

      ```
      print "world" + "baz" + "bar";
      print 27 - 26;
      print "bar" == "quz";
      ```

      Expected Output:

      ```
      worldbazbar
      1
      false
      ```

      Test Case 2:

      Input:

      ```
      print "hello"; print true;
      print false;
      print "bar"; print 43;
      ```

      Expected Output:

      ```
      hello
      true
      false
      bar
      43
      ```

      Test Case 3:

      Input:

      ```
      print 81;
          print 81 + 46;
              print 81 + 46 + 19;
      ```

      Expected Output:

      ```
      81
      127
      146
      ```

      Test Case 4:

      Input:

      ```
      print true != true;

      print "36
      10
      78
      ";

      print "There should be an empty line above this.";
      ```

      Expected Output:

      ```
      false
      36
      10
      78

      There should be an empty line above this.
      ```

      The tester will assert that the stdout of your program matches the format above, and that the exit code is 0.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/string/literals.lox)
    marketing_md: |-
      In this stage, you'll add support for handling multiple statements in a single `program`.

  - slug: "fi3"
    primary_extension_slug: "statements-and-state"
    name: "Expression statements"
    difficulty: easy
    description_md: |-
      In this stage, you'll add support for handling expression statements. An expression statement lets you place an expression where a statement is expected. They exist to evaluate expressions that have side effects.

      ### Book reference

      The code for this stage is implemented in [Section 8.1: Statements](https://craftinginterpreters.com/statements-and-state.html#statements).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain expressions that have side effects, combined with the `print` statement.

      For example, if `test.lox` contains the following

      ```
      "foo" + "bar";
      print "baz";
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh run test.lox
      baz
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      Test Case 1:

      Input:

      ```
      (37 + 42 - 21) > (76 - 37) * 2;
      print !false;
      "baz" + "hello" + "quz" + "bar" == "bazhelloquzbar";
      print !false;
      ```

      Expected Output:

      ```
      true
      true
      ```

      Test Case 2:

      Input:

      ```
      27 - 60 >= -99 * 2 / 99 + 76;
      true == true;
      ("world" == "bar") == ("baz" != "hello");
      print true;
      ```

      Expected Output:

      ```
      true
      ```

      Test Case 3:

      Input:

      ```
      print "the expression below is invalid";
      49 + "baz";
      print "this should not be printed";
      ```

      Expected Output:

      ```
      the expression below is invalid
      Operands must be two numbers or two strings.
      [line 2]
      ```

      Test Case 4:

      Input:

      ```
      print "79" + "baz";
      print false * (18 + 84);
      ```

      Expected Output:

      ```
      79baz
      Operands must be numbers.
      [line 2]
      ```

      The tester will assert that the stdout of your program matches the format above, and that the exit code is 0.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/string/literals.lox)
    marketing_md: |-
      In this stage, you'll add support for handling expression statements.

  - slug: "yg2"
    primary_extension_slug: "statements-and-state"
    name: "Variables: Declare variables"
    difficulty: easy
    description_md: |-
      In this stage, you'll add support for declaring variables using the `var` statement. For this, you'll need to add support for the `var` declaration in your AST generator, parser & interpreter.

      ### Book reference

      The code for this stage is implemented in [Section 8.2: Global Variables](https://craftinginterpreters.com/statements-and-state.html#global-variables).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain the `var` statement.

      For example, if `test.lox` contains the following

      ```
      var a = "foo";
      print a;
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh run test.lox
      foo
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      Test Case 1:

      Input:

      ```
      var world = 10;
      print world;
      ```

      Expected Output:

      ```
      10
      ```

      Test Case 2:

      Input:

      ```
      var bar = 99;
      var foo = 99;
      print bar + foo;
      var quz = 99;
      print bar + foo + quz;
      ```

      Expected Output:

      ```
      198
      297
      ```

      Test Case 3:

      Input:

      ```
      var foo = (8 * (62 + 62)) / 4 + 62;
      print foo;
      ```

      Expected Output:

      ```
      310
      ```

      Test Case 4:

      Input:

      ```
      var quz = 76;
      var baz = quz;
      print baz + quz;
      ```

      Expected Output:

      ```
      152
      ```

      The tester will assert that the stdout of your program matches the format above, and that the exit code is 0.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/variable/in_nested_block.lox)
    marketing_md: |-
      In this stage, you'll add support for declaring variables using the `var` statement.

  - slug: "sv7"
    primary_extension_slug: "statements-and-state"
    name: "Variables: Runtime Errors"
    difficulty: easy
    description_md: |-
      In this stage, you'll add support for handling runtime errors while accessing variables that haven't been declared yet.

      ### Book reference

      The code for this stage is implemented in [Section 8.2: Global Variables](https://craftinginterpreters.com/statements-and-state.html#global-variables).

      ### Tests

      The tester will run a series of tests with `test.lox` files that access variables that haven't been declared yet.

      For example, if `test.lox` contains the following

      ```
      print a;
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh run test.lox
      Undefined variable 'a'.
      [line 1]
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      Test Case 1:

      Input:

      ```
      print 22;
      print x;
      ```

      Expected Output:

      ```
      22
      Undefined variable 'x'.
      [line 2]
      ```

      Test Case 2:

      Input:

      ```
      var baz = 96;
      print hello;
      ```

      Expected Output:

      ```
      Undefined variable 'hello'.
      [line 2]
      ```

      Test Case 3:

      Input:

      ```
      var hello = 85;
      var result = (hello + bar) / world;
      print result;
      ```

      Expected Output:

      ```
      Undefined variable 'bar'.
      [line 2]
      ```

      Test Case 4:

      Input:

      ```
      var quz = 20;
      var world = 51;
      var hello = 56;
      print quz + world + he
      ```

      Expected Output:

      ```
      Undefined variable 'bar'.
      [line 4]
      ```

      The tester will assert that the exit code is 70, signifying a runtime error. Note that this is different from the expected exit code for a syntax error, which is 65.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/variable/in_nested_block.lox)
    marketing_md: |-
      In this stage, you'll add support for declaring variables using the `var` statement.

  - slug: "bc1"
    primary_extension_slug: "statements-and-state"
    name: "Variables: Initialize variables"
    difficulty: easy
    description_md: |-
      In this stage, you'll add support for initializing variables with the value passed to the `var` statement, or initializing them with `nil` if no value is passed.

      ### Book reference

      The code for this stage is implemented in [Section 8.2: Global Variables](https://craftinginterpreters.com/statements-and-state.html#global-variables).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain the `var` statement.

      For example, if `test.lox` contains the following

      ```
      var a;
      print a;
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh run test.lox
      nil
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      Test Case 1:

      Input:

      ```
      var foo;
      print foo;
      ```

      Expected Output:

      ```
      nil
      ```

      Test Case 2:

      Input:

      ```
      var baz = "foo";
      var bar;
      print bar;
      ```

      Expected Output:

      ```
      nil
      ```

      Test Case 3:

      Input:

      ```
      var baz = 69;
      var world;
      var quz;
      print world;
      ```

      Expected Output:

      ```
      nil
      ```

      Test Case 4:

      Input:

      ```
      var quz = 73 + 26 * 20;
      print quz;
      var hello = 26 * 20;
      print quz + hello;
      var foo;
      print foo;
      ```

      Expected Output:

      ```
      593
      1113
      nil
      ```

      The tester will assert that the stdout of your program matches the format above, and that the exit code is 0.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/variable/in_nested_block.lox)
    marketing_md: |-
      In this stage, you'll add support for initializing variables.

  - slug: "dw9"
    primary_extension_slug: "statements-and-state"
    name: "Variables: Redeclare variables"
    difficulty: easy
    description_md: |-
      In this stage, you'll add support for redeclaring variables using the `var` statement.

      ### Book reference

      The code for this stage is implemented in [Section 8.2: Global Variables](https://craftinginterpreters.com/statements-and-state.html#global-variables).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain the `var` statement.

      For example, if `test.lox` contains the following

      ```
      var a = 1;
      var a = 2;
      print a;
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh run test.lox
      2
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      Test Case 1:

      Input:

      ```
      var baz = "before";
      print baz;
      var baz = "after";
      print baz;
      ```

      Expected Output:

      ```
      before
      after
      ```

      Test Case 2:

      Input:

      ```
      var hello = "after";
      var hello = "before";
      var hello = hello;
      print hello;
      ```

      Expected Output:

      ```
      before
      ```

      Test Case 3:

      Input:

      ```
      var world = 2;
      print world;
      var world = 3;
      print world;
      var hello = 5;
      print hello;
      var world = hello;
      print world;
      ```

      Expected Output:

      ```
      2
      3
      5
      5
      ```

      Test Case 4:

      Input:

      ```
      var baz = bar;
      ```

      Expected Output:

      ```
      Undefined variable 'bar'.
      [line 1]
      ```

      The tester will assert that the stdout of your program matches the format above, and that the exit code is 0.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/variable/in_nested_block.lox)
    marketing_md: |-
      In this stage, you'll add support for redeclaring variables.

  - slug: "pl3"
    primary_extension_slug: "statements-and-state"
    name: "Assignment operation"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for assigning values to variables using the `=` operator. You need to only support variables that have already been declared on the left side of the assignment.
      Note that assignment is right associative, so `a = b = 1` is equivalent to `a = (b = 1)`.

      ### Book reference

      The code for this stage is implemented in [Section 8.4: Assignment](https://craftinginterpreters.com/statements-and-state.html#assignment).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain the assignment operation.

      For example, if `test.lox` contains the following

      ```
      var a;
      var b = 2;
      var a = b = 1;
      print a;
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh run test.lox
      1
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      Test Case 1:

      Input:

      ```
      var quz;
      quz = 1;
      print quz;
      print quz = 2;
      print quz;
      ```

      Expected Output:

      ```
      1
      2
      2
      ```

      Test Case 2:

      Input:

      ```
      var hello = 93;
      var bar = 93;
      bar = hello;
      hello = bar;
      print hello + bar;
      ```

      Expected Output:

      ```
      186
      ```

      Test Case 3:

      Input:

      ```
      var quz;
      var hello;

      quz = hello = 16 + 34 * 92;
      print quz;
      print hello;
      ```

      Expected Output:

      ```
      3144
      3144
      ```

      Test Case 4:

      Input:

      ```
      var hello = 65;
      var baz;
      var quz;

      hello = baz = quz = hello * 2;
      print hello;
      print baz;
      print baz;
      ```

      Expected Output:

      ```
      130
      130
      130
      ```

      The tester will assert that the stdout of your program matches the format above, and that the exit code is 0.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/string/literals.lox)
    marketing_md: |-
      In this stage, you'll add support for the assignment operation (=).

  - slug: "vr5"
    primary_extension_slug: "statements-and-state"
    name: "Block syntax"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for block syntax in your interpreter. Blocks are enclosed in curly braces `{}` and are used to group statements together. They are also used to create local scopes. We will test scopes in the next stage, in this stage you just need to handle the block syntax.

      ### Book reference

      The code for this stage is implemented in [Section 8.5.2: Block syntax and semantics](https://craftinginterpreters.com/statements-and-state.html#block-syntax-and-semantics).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain the assignment operation.

      For example, if `test.lox` contains the following

      ```
      {
          var foo = "before";
          print foo;
      }
      {
          var foo = "after";
          print foo;
      }
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh run test.lox
      before
      after
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      Test Case 1:

      Input:

      ```
      {
          var hello = "baz";
          print hello;
      }
      ```

      Expected Output:

      ```
      baz
      ```

      Test Case 2:

      Input:

      ```
      {
          var world = "before";
          print world;
      }
      {
          var world = "after";
          print world;
      }
      ```

      Expected Output:

      ```
      before
      after
      ```

      Test Case 3:

      Input:

      ```
      {
          var hello = 88;
          {
              var foo = 88;
              print foo;
          }
          print hello;
      }
      ```

      Expected Output:

      ```
      88
      88
      ```

      Test Case 4:

      Input:

      ```
      {
          var bar = 11;
          var world = 11;
          {
              print bar + world;
      }
      ```

      Expected Output:

      ```
      [line 6] Error at end: Expect '}' .
      ```

      The tester will assert that the stdout of your program matches the format above, and that the exit code is 0. If there is any blocks that are opened but not closed, it should throw a syntax error, the exit code in that case should be 65.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/string/literals.lox)
    marketing_md: |-
      In this stage, you'll add support for block syntax using curly braces `{}`.

  - slug: "fb4"
    primary_extension_slug: "statements-and-state"
    name: "Scopes"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for scopes in your interpreter. Scopes are created by blocks, and they are used to group variables together. We will test variables in local scopes, nested scopes, shadowing of variables, and accessing variables outside of the scope where they are defined.

      ### Book reference

      The code for this stage is implemented in [Section 8.5: Scope](https://craftinginterpreters.com/statements-and-state.html#scope).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain the assignment operation.

      For example, if `test.lox` contains the following

      ```
      {
          var world = "before";
          {
              var world = "after";
              print world;
          }
          print world;
      }
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh run test.lox
      after
      before
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      Test Case 1:

      Input:

      ```
      var baz = (91 * 16) - 61;
      {
          var world = "quz" + "89";
          print world;
      }
      print baz;
      ```

      Expected Output:

      ```
      quz89
      1395
      ```

      Test Case 2:

      Input:

      ```
      {
          var quz = "before";
          {
              var quz = "after";
              print quz;
          }
          print quz;
      }
      ```

      Expected Output:

      ```
      after
      before
      ```

      Test Case 3:

      Input:

      ```
      var bar = "global bar";
      var world = "global world";
      var hello = "global hello";
      {
        var bar = "outer bar";
        var world = "outer world";
        {
          var bar = "inner bar";
          print bar;
          print world;
          print hello;
        }
        print bar;
        print world;
        print hello;
      }
      print bar;
      print world;
      print hello;
      ```

      Expected Output:

      ```
      inner bar
      outer world
      global hello
      outer bar
      outer world
      global hello
      global bar
      global world
      global hello
      ```

      Test Case 4:

      Input:

      ```
      {
        var hello = "outer hello";
        {
          var hello = "inner hello";
          print hello;
        }
        print hello;
      }
      print hello;
      ```

      Expected Output:

      ```
      inner hello
      outer hello
      Undefined variable 'hello'.
      [line 9]
      ```

      The tester will assert that the stdout of your program matches the format above, and that the exit code is 0. Accessing a variable outside of its scope should throw a runtime error, the exit code in that case should be 70.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/01e6f5b8f3e5dfa65674c2f9cf4700d73ab41cf8/test/string/literals.lox)
    marketing_md: |-
      In this stage, you'll add support for scopes in your interpreter.

  - slug: "ne3"
    primary_extension_slug: "control-flow"
    name: "If statements"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for the `if` statement in your interpreter. The `if` statement is used to conditionally execute statements based on a boolean condition.

      ### Book reference

      The code for this stage is implemented in [Section 9.2: Conditional execution](https://craftinginterpreters.com/control-flow.html#conditional-execution).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain programs with `if` statements.

      For example, if `test.lox` contains the following

      ```
      if (true) print "good";
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh run test.lox
      good
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      Test Case 1:

      Input:

      ```
      if (true) print "bar";
      ```

      Expected Output:

      ```
      bar
      ```

      Test Case 2:

      Input:

      ```
      if (true) {
        print "block body";
      }
      ```

      Expected Output:

      ```
      block body
      ```

      Test Case 3:

      Input:

      ```
      var a = false;
      if (a = true) {
        print (a == true);
      }
      ```

      Expected Output:

      ```
      true
      ```

      Test Case 4:

      Input:

      ```
      var stage = "unknown";
      var age = 50;
      if (age < 18) { stage = "child"; }
      if (age >= 18) { stage = "adult"; }
      print stage;

      var isAdult = age >= 18;
      if (isAdult) { print "eligible for voting: true"; }
      if (!isAdult) { print "eligible for voting: false"; }
      ```

      Expected Output:

      ```
      adult
      eligible for voting: true
      ```

      The tester will assert that the stdout of your program matches the format above, and that the exit code is 0.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/4a840f70f69c6ddd17cfef4f6964f8e1bcd8c3d4/test/if/if.lox)
    marketing_md: |-
      In this stage, you'll add support for the `if` statement in your interpreter.

  - slug: "st5"
    primary_extension_slug: "control-flow"
    name: "Else statements"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for the `else` statement in your interpreter. The `else` statement is used to conditionally execute statements when the `if` condition is false.

      ### Book reference

      The code for this stage is implemented in [Section 9.2: Conditional execution](https://craftinginterpreters.com/control-flow.html#conditional-execution).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain programs with `if` statements.

      For example, if `test.lox` contains the following

      ```
      if (true) print "if branch"; else print "else branch";
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh run test.lox
      if branch
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      Test Case 1:

      Input:

      ```
      if (true) print "if branch"; else print "else branch";
      ```

      Expected Output:

      ```
      if branch
      ```

      Test Case 2:

      Input:

      ```
      var age = 21;
      if (age > 18) print "adult"; else print "child";
      ```

      Expected Output:

      ```
      adult
      ```

      Test Case 3:

      Input:

      ```
      if (false) {
        print "if block";
      } else print "else statement";

      if (false) print "if statement"; else {
        print "else block";
      }
      ```

      Expected Output:

      ```
      else statement
      else block
      ```

      Test Case 4:

      Input:

      ```
      var celsius = 67;
      var fahrenheit = 0;
      var isHot = false;

      {
        fahrenheit = celsius * 9 / 5 + 32;
        print celsius; print fahrenheit;

        if (celsius > 30) {
          isHot = true;
          print "It's a hot day. Stay hydrated!";
        } else {
          print "It's cold today. Wear a jacket!";
        }

        if (isHot) { print "Remember to use sunscreen!"; }
      }
      ```

      Expected Output:

      ```
      67
      152.6
      It's a hot day. Stay hydrated!
      Remember to use sunscreen!
      ```

      The tester will assert that the stdout of your program matches the format above, and that the exit code is 0.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/4a840f70f69c6ddd17cfef4f6964f8e1bcd8c3d4/test/if/else.lox)
    marketing_md: |-
      In this stage, you'll add support for the `else` statement in your interpreter.

  - slug: "fh8"
    primary_extension_slug: "control-flow"
    name: "Else-if statements"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for the `else-if` statement in your interpreter. The `else-if` statement is used to conditionally execute statements when the `if` condition is false.

      ### Book reference

      The code for this stage is implemented in [Section 9.2: Conditional execution](https://craftinginterpreters.com/control-flow.html#conditional-execution).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain programs with `if` statements.

      For example, if `test.lox` contains the following

      ```
      if (false) print "if branch"; else if (false) print "else-if branch";
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh run test.lox
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      Test Case 1:

      Input:

      ```
      if (true) print "if branch"; else if (false) print "else-if branch";
      ```

      Expected Output:

      ```
      if branch
      ```

      Test Case 2:

      Input:

      ```
      if (true) {
        print "hello";
      } else if (true) print "hello";

      if (true) print "hello"; else if (true) {
        print "hello";
      }
      ```

      Expected Output:

      ```
      hello
      hello
      ```

      Test Case 3:

      Input:

      ```
      var age = 88;
      var stage = "unknown";
      if (age < 18) { stage = "child"; }
      else if (age >= 18) { stage = "adult"; }
      else if (age >= 65) { stage = "senior"; }
      else if (age >= 100) { stage = "centenarian"; }
      print stage;
      ```

      Expected Output:

      ```
      adult
      ```

      Test Case 4:

      Input:

      ```
      var age = 67;

      var isAdult = age >= 18;
      if (isAdult) { print "eligible for voting: true"; }
      else { print "eligible for voting: false"; }

      if (age < 16) { print "eligible for driving: false"; }
      else if (age < 18) { print "eligible for driving: learner's permit"; }
      else { print "eligible for driving: full license"; }

      if (age < 21) { print "eligible for drinking (US): false"; }
      else { print "eligible for drinking (US): true"; }
      ```

      Expected Output:

      ```
      eligible for voting: true
      eligible for driving: full license
      eligible for drinking (US): true
      ```

      The tester will assert that the stdout of your program matches the format above, and that the exit code is 0.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/4a840f70f69c6ddd17cfef4f6964f8e1bcd8c3d4/test/if/else.lox)
    marketing_md: |-
      In this stage, you'll add support for the `else-if` statement in your interpreter.

  - slug: "xj4"
    primary_extension_slug: "control-flow"
    name: "Nested if statements"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for nested `if` statements in your interpreter. Nested `if` statements are `if` statements that are inside the body of another `if` statement.

      ### Book reference

      The code for this stage is implemented in [Section 9.2: Conditional execution](https://craftinginterpreters.com/control-flow.html#conditional-execution).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain programs with `if` statements.

      For example, if `test.lox` contains the following

      ```
      if (true) if (true) print "nested true";
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh run test.lox
      nested true
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      Test Case 1:

      Input:

      ```
      if (true) if (true) print "nested true";
      ```

      Expected Output:

      ```
      nested true
      ```

      Test Case 2:

      Input:

      ```
      if (true) {
        if (false) print "quz"; else print "quz";
      }
      ```

      Expected Output:

      ```
      quz
      ```

      Test Case 3:

      Input:

      ```
      var stage = "unknown";
      var age = 29;
      if (age < 18) {
          if (age < 13) { stage = "child"; }
          else if (age < 16) { stage = "young teenager"; }
          else { stage = "teenager"; }
      }
      else if (age < 65) {
          if (age < 30) { stage = "young adult"; }
          else if (age < 50) { stage = "adult"; }
          else { stage = "middle-aged adult"; }
      }
      else { stage = "senior"; }
      print stage;

      var isAdult = age >= 18;
      if (isAdult) {
          print "eligible for voting: true";
          if (age < 25) {
              print "first-time voter: likely";
          }
          else { print "first-time voter: unlikely"; }
      }
      else { print "eligible for voting: false"; }

      if (age < 16) { print "eligible for driving: false"; }
      else if (age < 18) {
          print "eligible for driving: learner's permit";
          if (age < 17) { print "supervised driving required"; }
          else { print "unsupervised driving allowed with restrictions"; }
      }
      else { print "eligible for driving: full license"; }

      if (age < 21) { print "eligible for drinking (US): false"; }
      else {
          print "eligible for drinking (US): true";
          if (age < 25) { print "remember: drink responsibly!"; }
      }
      ```

      Expected Output:

      ```
      young adult
      eligible for voting: true
      first-time voter: unlikely
      eligible for driving: full license
      eligible for drinking (US): true
      ```

      Test Case 4:

      Input:

      ```
      if (true) if (false) print "world"; else print "baz";
      ```

      Expected Output:

      ```
      baz
      ```

      The tester will assert that the stdout of your program matches the format above, and that the exit code is 0.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/4a840f70f69c6ddd17cfef4f6964f8e1bcd8c3d4/test/if/dangling_else.lox)
    marketing_md: |-
      In this stage, you'll add support for nested `if` statements in your interpreter.

  - slug: "wk8"
    primary_extension_slug: "control-flow"
    name: "Logical OR operator"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for the logical OR operator in your interpreter. The logical OR operator is used to combine two conditions and return true if either condition is true.

      ### Book reference

      The code for this stage is implemented in [Section 9.3: Logical Operators](https://craftinginterpreters.com/control-flow.html#logical-operators).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain programs with the logical OR operator.

      For example, if `test.lox` contains the following

      ```
      print nil or "ok";
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh run test.lox
      ok
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      Test Case 1:

      Input:

      ```
      if (false or "ok") print "baz";
      if (nil or "ok") print "baz";

      if (false or false) print "world";
      if (true or "world") print "world";

      if (24 or "bar") print "bar";
      if ("bar" or "bar") print "bar";
      ```

      Expected Output:

      ```
      baz
      baz
      world
      bar
      bar
      ```

      Test Case 2:

      Input:

      ```
      print 41 or true;
      print false or 41;
      print false or false or true;

      print false or false;
      print false or false or false;
      print true or true or true or true;
      ```

      Expected Output:

      ```
      41
      41
      true
      false
      false
      true
      ```

      Test Case 3:

      Input:

      ```
      var a = "hello";
      var b = "hello";
      (a = false) or (b = true) or (a = "hello");
      print a;
      print b;
      ```

      Expected Output:

      ```
      false
      true
      ```

      Test Case 4:

      Input:

      ```
      var stage = "unknown";
      var age = 23;
      if (age < 18) { stage = "child"; }
      if (age >= 18) { stage = "adult"; }
      print stage;

      var isAdult = age >= 18;
      if (isAdult) { print "eligible for voting: true"; }
      if (!isAdult) { print "eligible for voting: false"; }
      ```

      Expected Output:

      ```
      adult
      eligible for voting: true
      ```

      The tester will assert that the stdout of your program matches the format above, and that the exit code is 0.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/4a840f70f69c6ddd17cfef4f6964f8e1bcd8c3d4/test/logical_operator/or.lox)
    marketing_md: |-
      In this stage, you'll add support for the logical OR operator in your interpreter.

  - slug: "jx4"
    primary_extension_slug: "control-flow"
    name: "Logical AND operator"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for the logical AND operator in your interpreter. The logical AND operator is used to combine two conditions and return true only if both conditions are true.

      ### Book reference

      The code for this stage is implemented in [Section 9.4: Logical Operators](https://craftinginterpreters.com/control-flow.html#logical-operators).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain programs with the logical AND operator.

      For example, if `test.lox` contains the following

      ```
      print false and "ok";
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh run test.lox
      false
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      Test Case 1:

      Input:

      ```
      if (false and "bad") print "foo";
      if (nil and "bad") print "foo";

      if (true and "hello") print "hello";
      if (97 and "baz") print "baz";
      if ("baz" and "baz") print "baz";
      if ("" and "bar") print "bar";
      ```

      Expected Output:

      ```
      hello
      baz
      baz
      bar
      ```

      Test Case 2:

      Input:

      ```
      print false and 1;
      print true and 1;
      print 23 and "hello" and false;

      print 23 and true;
      print 23 and "hello" and 23;
      ```

      Expected Output:

      ```
      false
      1
      false
      true
      23
      ```

      Test Case 3:

      Input:

      ```
      var a = "quz";
      var b = "quz";
      (a = true) and (b = false) and (a = "bad");
      print a;
      print b;
      ```

      Expected Output:

      ```
      true
      false
      ```

      Test Case 4:

      Input:

      ```
      var stage = "unknown";
      var age = 14;
      if (age < 18) { stage = "child"; }
      if (age >= 18) { stage = "adult"; }
      print stage;

      var isAdult = age >= 18;
      if (isAdult) { print "eligible for voting: true"; }
      if (!isAdult) { print "eligible for voting: false"; }
      ```

      Expected Output:

      ```
      child
      eligible for voting: false
      ```

      The tester will assert that the stdout of your program matches the format above, and that the exit code is 0.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/4a840f70f69c6ddd17cfef4f6964f8e1bcd8c3d4/test/logical_operator/and.lox)
    marketing_md: |-
      In this stage, you'll add support for the logical AND operator in your interpreter.

  - slug: "qy3"
    primary_extension_slug: "control-flow"
    name: "While statements"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for `while` statements in your interpreter. `while` statements are used to execute a block of code repeatedly while a condition is true.

      ### Book reference

      The code for this stage is implemented in [Section 9.4: While loops](https://craftinginterpreters.com/control-flow.html#while-loops).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain programs with `while` statements.

      For example, if `test.lox` contains the following

      ```
      var foo = 0;
      while (foo < 3) print foo = foo + 1;
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh run test.lox
      1
      2
      3
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      Test Case 1:

      Input:

      ```
      var foo = 0;
      while (foo < 3) print foo = foo + 1;
      ```

      Expected Output:

      ```
      1
      2
      3
      ```

      Test Case 2:

      Input:

      ```
      var quz = 0;
      while (quz < 3) {
        print quz;
        quz = quz + 1;
      }
      ```

      Expected Output:

      ```
      0
      1
      2
      ```

      Test Case 3:

      Input:

      ```
      while (false) {
        print "should not print";
      }

      var product = 1;
      var i = 1;

      while (i <= 5) {
        product = product * i;
        i = i + 1;
      }

      print "Product of numbers 1 to 5: "; print product;
      ```

      Expected Output:

      ```
      Product of numbers 1 to 5: 
      120
      ```

      Test Case 4:

      Input:

      ```
      var n = 10;
      var fm = 0;
      var fn = 1;
      var index = 0;

      while (index < n) {
        print fm;
        var temp = fm;
        fm = fn;
        fn = temp + fn;
        index = index + 1;
      }
      ```

      Expected Output:

      ```
      0
      1
      1
      2
      3
      5
      8
      13
      21
      34
      ```

      The tester will assert that the stdout of your program matches the format above, and that the exit code is 0.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/4a840f70f69c6ddd17cfef4f6964f8e1bcd8c3d4/test/while/syntax.lox)
    marketing_md: |-
      In this stage, you'll add support for `while` statements in your interpreter.

  - slug: "bw6"
    primary_extension_slug: "control-flow"
    name: "For statements"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for the `for` statement in your interpreter. The `for` statement executes a block of code repeatedly using a “initializer” clause, a “condition” clause and an “increment” clause.

      ### Book reference

      The code for this stage is implemented in [Section 9.5: For Loops](https://craftinginterpreters.com/control-flow.html#for-loops).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain programs with `if` statements.

      For example, if `test.lox` contains the following

      ```
      for (var baz = 0; baz < 3;) print baz = baz + 1;
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh run test.lox
      1
      2
      3
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      Test Case 1:

      Input:

      ```
      for (var baz = 0; baz < 3;) print baz = baz + 1;
      ```

      Expected Output:

      ```
      1
      2
      3
      ```

      Test Case 2:

      Input:

      ```
      for (var world = 0; world < 3; world = world + 1) {
        print world;
      }
      ```

      Expected Output:

      ```
      0
      1
      2
      ```

      Test Case 3:

      Input:

      ```
      var world = 0;
      for (; world < 2; world = world + 1) print world;

      for (var foo = 0; foo < 2;) {
        print foo;
        foo = foo + 1;
      }
      ```

      Expected Output:

      ```
      0
      1
      0
      1
      ```

      Test Case 4:

      Input:

      ```
      var quz = "after";
      {
        var quz = "before";

        for (var quz = 0; quz < 1; quz = quz + 1) {
          print quz;
          var quz = -1;
          print quz;
        }
      }

      {
        for (var quz = 0; quz > 0; quz = quz + 1) {}

        var quz = "after";
        print quz;

        for (quz = 0; quz < 1; quz = quz + 1) {
          print quz;
        }
      }
      ```

      Expected Output:

      ```
      0
      -1
      after
      0
      ```

      The tester will assert that the stdout of your program matches the format above, and that the exit code is 0.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/4a840f70f69c6ddd17cfef4f6964f8e1bcd8c3d4/test/for/syntax.lox)
    marketing_md: |-
      In this stage, you'll add support for `for` statements in your interpreter.

  - slug: "vt1"
    primary_extension_slug: "control-flow"
    name: "Syntactic errors"
    difficulty: medium
    description_md: |-
      In this stage, you'll add support for syntactic errors in your interpreter. Syntactic errors are errors that occur when the code is not written in the correct syntax.

      ### Book reference

      The code for this stage is implemented in [Section 9.5: For Loops](https://craftinginterpreters.com/control-flow.html#for-loops).

      ### Tests

      The tester will run a series of tests with `test.lox` files that contain programs with syntactic errors.

      For example, if `test.lox` contains the following

      ```
      for (;;) var foo;
      ```

      The tester will run your program like this:

      ```
      $ ./your_program.sh run test.lox
      [line 1] Error at 'var': Expect expression.
      ```

      The tester will run multiple such tests with randomized expressions, for example:

      Test Case 1:

      Input:

      ```
      if (true) "ok"; else var foo;
      ```

      Expected Output:

      ```
      [line 1] Error at 'var': Expect expression.
      ```

      Test Case 2:

      Input:

      ```
      for (var a = 1; {}; a = a + 1) {}
      ```

      Expected Output:

      ```
      [line 2] Error at '{': Expect expression.
      [line 2] Error at ')': Expect ';' after expression.
      ```

      Test Case 3:

      Input:

      ```
      for (var a = 1; a < 2; {}) {}
      ```

      Expected Output:

      ```
      [line 2] Error at '{': Expect expression.
      ```

      Test Case 4:

      Input:

      ```
      for ({}; a < 2; a = a + 1) {}
      ```

      Expected Output:

      ```
      [line 2] Error at '{': Expect expression.
      [line 2] Error at ')': Expect ';' after expression.
      ```

      The tester will only assert that the exit code is 65, when there is a compilation error.

      ### Notes

      - This output format matches the spec in the [book's repository](https://github.com/munificent/craftinginterpreters/blob/4a840f70f69c6ddd17cfef4f6964f8e1bcd8c3d4/test/if/dangling_else.lox)
    marketing_md: |-
      In this stage, you'll handle several syntactic errors in your interpreter.