# Module 6: Grid, lexer and parser
This is the first module of Part II. In Part I the rules lived inside the cards: Harvest Golem's Deathrattle was a clause on Harvest Golem, and your engine's job was to find the right clause at the right moment and run it. Part II turns that around. In Baba Is You the objects on the board have no behaviour at all. A rock is just a rock until some text on the board says `ROCK IS PUSH`. Every rule comes from words lying on the grid, and the words can be pushed around, so the rules change while you play. The engine's job is now to *compile* the rules from the board, and to compile them again every time the board changes.
This module builds the compiler's front end: a grid that holds objects and text, a lexer that turns text into words with grammatical roles, and a parser that turns words into rules. Nothing moves yet (that is Module 8), and no rule does anything yet (Modules 7 and 9). By the end, `rules()` reads any board you build.
You need your Module 5 workspace with all Module 1–5 tests passing, under git. Part I's engine stays where it is, and its tests keep running: Part II is a second engine next to the first, in the same project. Part III will plug them together.
## Observe
All quotes in this module come from sources recorded in the course's research notes. The Baba Is You Wiki is an unofficial community wiki, and the course treats it as the best available description of the game, not as Hempuli's own word.
How a sentence reads, from the wiki's [Rule](https://babaiswiki.fandom.com/wiki/Rule) page:
> Rules read from left to right in a row, or from top to bottom in a column.
A noun can take a property or another noun ([Category:Nouns](https://babaiswiki.fandom.com/wiki/Category:Nouns)):
> A noun can be used as a NOUN RULE PROPERTY statement e.g. BABA IS YOU to give it a property or as a NOUN IS NOUN statement eg. WALL IS WATER to turn an object into another object.
Sentences can cross. The [Esolangs wiki](https://esolangs.org/wiki/Baba_Is_You) says "multiple rules are able to cross and overlap if the parsing rules allow for a valid statement", so one `IS` can sit in a row sentence and a column sentence at once.
`AND` joins words on either side of `IS`. The [AND](https://babaiswiki.fandom.com/wiki/AND) page calls it "mechanically equivalent to each rule being defined individually", and gives this table row:
> BABA AND KEKE IS PUSH AND STOP = BABA IS PUSH, BABA IS STOP, KEKE IS PUSH, KEKE IS STOP
Text can share a tile. The [Rule](https://babaiswiki.fandom.com/wiki/Rule) page: "If more than one parsable object is stacked, the game will attempt to produce all possible rules." The game's designer, Arvi "Hempuli" Teikari, told Game Developer that this was one of the hard parts: "the stacking adds the need to go through all the possible permutations a rule could have" ([Designing Baba Is You's delightfully innovative rule-writing system](https://www.gamedeveloper.com/design/designing-i-baba-is-you-i-s-delightfully-innovative-rule-writing-system)).
Some rules have no text at all. Again from [Rule](https://babaiswiki.fandom.com/wiki/Rule):
> The following rules are enabled by default, even though there isn't any text saying so. TEXT IS PUSH, LEVEL IS STOP, CURSOR IS SELECT. These rules can still be detected by FEELING and MIMIC and negated by NOT and BROKEN. These rules are not listed in the pause menu.
That is why you can push text around although no sentence says so. `TEXT` is a noun about text itself ([TEXT](https://babaiswiki.fandom.com/wiki/TEXT)).
And when the rules are worked out. The [Rule](https://babaiswiki.fandom.com/wiki/Rule) page: "Rules parse when any parsable object changes position or is destroyed, or an object is transformed to text. Between parsings, active rules are simply stored." Teikari describes the same thing from the inside (same Game Developer article): "The game only updates the rules if it needs to", and when it does, "The previous rules are removed entirely, and words that could potentially start rule sentences are detected on the level."
Read that last quote twice. The game doesn't edit its rule list when a word moves. It throws the list away and reads the board again.
## Predict
Write your answers down before you open the discussion, for example in `notes/06.md` in your workspace. Coordinates are (x, y), with x growing right and y growing down.
1. Text `BABA` (0,1), `IS` (1,1), `YOU` (2,1), `FLAG` (1,0), `WIN` (1,2). Draw it. Which rules does it spell?
2. One row: `BABA AND ROCK IS PUSH AND STOP`. How many rules? Which?
3. Text `BABA` and text `ROCK` both on (0,0), then `IS` (1,0), `YOU` (2,0). Which rules?
4. One row: `YOU IS FLAG`. Which rules? And a level with no text at all?
5. Your Module 5 engine stored each card's behaviour on the card. Where would you store "Baba is YOU" here: on each Baba object, on the noun `BABA`, somewhere else? What has to happen when the `YOU` text is pushed out of line?
6. Your engine has to know that `IS` is special. Does it have to know that `BABA` is a noun?
Discussion
1. `BABA IS YOU` across the middle row and `FLAG IS WIN` down the middle column, sharing the `IS`. Plus `TEXT IS PUSH`, which is always there.
2. Four: `BABA IS PUSH`, `BABA IS STOP`, `ROCK IS PUSH`, `ROCK IS STOP`. AND distributes over both sides: two subjects times two complements.
3. `BABA IS YOU` and `ROCK IS YOU`. Each stacked word gets its turn as the start of the sentence: "all possible rules".
4. None from the text: a sentence must start with a noun, and `YOU` is a property. The parser never reads right to left, so it doesn't find `FLAG IS YOU` either. With no text at all, the rules are exactly `TEXT IS PUSH`.
5. Nowhere permanent. If "Baba is YOU" were stored on each Baba, pushing `YOU` away would have to find every Baba and take it back, and a Baba created later would have to look up what it missed. The rule belongs to a table derived from the board. Objects ask the table. When the board changes, the table is rebuilt: the game "removes the previous rules entirely".
6. It shouldn't. `IS`, `AND`, `NOT` are grammar, and the engine must know them to parse at all. `BABA`, `ROCK` and `FLAG` are vocabulary: the parser only needs to know each one's *role* (noun or property), and that can come from data. That is the Zero-Coupling Law of Part I, applied to words: the engine doesn't name nouns.
Hint 1 — nudge
Where does a sentence *begin*? You could try every noun on the board as a start and read right and down. That works, but `BABA AND ROCK IS PUSH` then reads twice: once from `BABA` and once from `ROCK`. Every sentence has exactly one `IS` in it. What if you start there and read outwards?
Hint 2 — concept
- **Start at every `IS`, twice**: once in its row, once in its column. Each `IS` is in at most one row sentence and one column sentence, so nothing is read twice.
- **Read a run outwards.** Before the `IS`, walking backwards, collect the nouns on the next tile; if the tile after them holds an `AND`, keep going from the tile after that. After the `IS`, the same, forwards, with nouns and properties. If the first tile has nothing that fits, the run is empty and the sentence spells nothing.
- **Stacking is free.** A tile is a list of words. "The nouns on this tile" is a list too, and every one of them goes into the run. Two stacked subjects and one complement are two rules, with no special case.
- **One rule per pair.** Subjects × complements. That is AND distributing.
- **Base rules first.** Start the list with `TEXT IS PUSH`, then add what the text spells.
- **Keep the text ids.** A rule can remember the three text objects that spelled it. Two copies of `BABA IS YOU` spelled by different text are two rules; the same text found from two directions can't happen when you start from `IS`.
Hint 3 — pseudo-code
```text
lex(board, words):
tiles = map (x, y) -> list of {id, word, role}
for each text object o, oldest first:
role = words.role(o.word) // IS AND NOT: operator, TEXT: noun, else from content
if role is known: tiles[o.x, o.y].push({o.id, o.word, role})
parse(board, words):
tiles = lex(board, words)
rules = [TEXT IS PUSH]
for each IS token t at (x, y):
for (dx, dy) in [(1, 0), (0, 1)]:
subjects = run(tiles, (x - dx, y - dy), (-dx, -dy), noun)
complements = run(tiles, (x + dx, y + dy), (dx, dy), noun or property)
for s in subjects, c in complements:
rules.push({s.word, c.word, text: [s.id, t.id, c.id]})
return rules
run(tiles, at, step, fits):
found = [w in tiles[at] where fits(w)]
if found is empty: return []
if tiles[at + step] has an AND:
found += run(tiles, at + 2 * step, step, fits)
return found
```
Discussion: what this drop measures
If your nouns and properties are data, `HOT` is one line:
```json
{ "name": "HOT", "role": "property" }
```
That is the whole reference answer, in `course/06-parser/expansion/solution/words.json` (the Module 6 word list with that line added), the same file for both tracks.
Shapes that fail this drop:
- **Properties as an enum in the engine.** If `Property::You | Property::Push | ...` lives under `src/engine/`, HOT is a new variant there. A typed enum feels safer, but every new word becomes an engine change, and the course's catalog alone lists fourteen properties.
- **The parser checks words, not roles.** If the complement test is `word == "YOU" || word == "PUSH" || ...`, the list of properties is in the parser. Move it to the lexer's input, and let the parser ask only "noun or property?".
- **Unknown words accepted as anything.** If your lexer treats every unknown word as a property, the test passes before the drop, and so does `BABA IS BANANA`. The drop's first run should fail.
If the check fails, fix your engine (a normal commit, outside the drop), then redo the drop from step 1.