Summary Files Commits Branches @commit @diff @stats
path: root / src / blog
diff options
context:
space:
mode:
Commit594b2cb3aa351a04064ea1f2ca62ad99318fd423 (patch)
Author
 Syndamia <kamen@syndamia.com>
2025-08-18 19:21:01 +0300
Committer
 Syndamia <kamen@syndamia.com>
2025-08-18 19:22:05 +0300
Filesb1de0bf1b2bbc1044b181fe177c4c3a1d0c6f649 /src/blog
syndamia.com-594b2cb3aa351a04064ea1f2ca62ad99318fd423.tar
syndamia.com-594b2cb3aa351a04064ea1f2ca62ad99318fd423.tar.gz
syndamia.com-594b2cb3aa351a04064ea1f2ca62ad99318fd423.zip
Parentc4808a20e5638f2c96124dd1a66f37e19d107bd5 (diff)
chore: Fix all errors
1 files changed, 7 insertions, 7 deletions
-rw-r--r--src/blog/sane-explanation-of-compilers/part-1.du14
diff --git a/src/blog/sane-explanation-of-compilers/part-1.du b/src/blog/sane-explanation-of-compilers/part-1.du
index d9b58ba..33d8a1a 100644
--- a/src/blog/sane-explanation-of-compilers/part-1.du
+++ b/src/blog/sane-explanation-of-compilers/part-1.du
@@ -658,7 +658,7 @@ If you want to learn more, I would highly suggest:
We already decided that the lexer will output tokens (and characters) to the parser, but we didn't talk about what the parser is supposed to output.
It definitely has to be some sort of structural representation of the overall code, for example, for `[3 + 1 * 2]` we have to be able to easily find out what the left and right handsides of the `[+]` and `[*]` are.
-'footnoe nomnoml The graphics are made with [url https://nomnoml.com/ nomnoml] by [url https://github.com/skanaar Daniel Kallin]
+'footnote nomnoml The graphics are made with [url https://nomnoml.com/ nomnoml] by [url https://github.com/skanaar Daniel Kallin]
Let's draw out[$nomnoml] this relationship, where the left arrow connects to the left handside and the right accordingly:
@@ -1065,20 +1065,20 @@ The way we created that lexer and parser worked, but it wasn't very useful and h
RULE1 { yylval.num = 129; return TOKEN; }
RULE2 { yylval.chr = 'a'; return TOKEN; }
- Inside C blocks for grammar rules we can reference the token values with `[$i]`, where `[i]` is the i'th "token" in the expression.
- For example, in this rule, `[$1]` would be `[(]`, `[$3]` would be value of token `[B]` and `[$5]` would be the value of the rule name:
+ Inside C blocks for grammar rules we can reference the token values with `[\$i]`, where `[i]` is the i'th "token" in the expression.
+ For example, in this rule, `[\$1]` would be `[(]`, `[\$3]` would be value of token `[B]` and `[\$5]` would be the value of the rule name:
```yacc
rule : ( A B ) rule
;
- You can set rule "return" values by setting the variable `[$$]`:
+ You can set rule "return" values by setting the variable `[\$$]`:
```yacc
rule : LBRACE rule RBRACE { $$ = 10; }
The way you set it's type is discussed later.
- However, `[$i]` isn't of type union, we cannot do something like `[$i.num]`, it is the precise value that was set for the token.
+ However, `[\$i]` isn't of type union, we cannot do something like `[\$i.num]`, it is the precise value that was set for the token.
Therefore, we also need to define which value from the union every token will set, which is done by adding `[<PROPERTY>]` before every defined token (and `[PROPERTY]` is a property name inside the union):
```yacc
@@ -1190,8 +1190,8 @@ The way we created that lexer and parser worked, but it wasn't very useful and h
For the expression of `[expr]` we'll "return" a node with the value of the math operator and left and right will be the returned values.
Inside start, after we've parsed an `[expr]`, we'll print out the "returned" tree and free it's memory.
- I'm putting returned in quotes, because (as mentioned), we'll just be setting the value of `[$$]`.
- `[$$]`'s type is set with the `[%type]` option, which works exactly like `[%token]`, but with grammar rule names.
+ I'm putting returned in quotes, because (as mentioned), we'll just be setting the value of `[\$$]`.
+ `[\$$]`'s type is set with the `[%type]` option, which works exactly like `[%token]`, but with grammar rule names.
However, this means that `[node]` must be available in `[%union]`, which is unfortunate but isn't a problem, we'll just add it.
Now, finally, it's time to include our `[tree.h]` in `[parser.y]`, but we'll also need to include it in `[lexer.l]`.