diff options
| Commit | 594b2cb3aa351a04064ea1f2ca62ad99318fd423 (patch) | |
|---|---|---|
| Author | 2025-08-18 19:21:01 +0300 | |
| Committer | 2025-08-18 19:22:05 +0300 | |
| Files | b1de0bf1b2bbc1044b181fe177c4c3a1d0c6f649 /src/blog | |
| syndamia.com-594b2cb3aa351a04064ea1f2ca62ad99318fd423.tar syndamia.com-594b2cb3aa351a04064ea1f2ca62ad99318fd423.tar.gz syndamia.com-594b2cb3aa351a04064ea1f2ca62ad99318fd423.zip | ||
| Parent | c4808a20e5638f2c96124dd1a66f37e19d107bd5 (diff) | |
chore: Fix all errors
1 files changed, 7 insertions, 7 deletions
| -rw-r--r-- | src/blog/sane-explanation-of-compilers/part-1.du | 14 |
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]`. |