Summary Files Commits Branches @commit @diff @stats
diff options
context:
space:
mode:
Commitb2377649aded6e17bc9c5aff60eafc5f963aad0d (patch)
Author
 Syndamia <kamen@syndamia.com>
2023-04-18 17:21:59 +0300
Committer
 Syndamia <kamen@syndamia.com>
2023-04-18 17:21:59 +0300
Files5dc3c075416012ea1f9fd0d4658c93f26355a1e7
syndamia.com-b2377649aded6e17bc9c5aff60eafc5f963aad0d.tar
syndamia.com-b2377649aded6e17bc9c5aff60eafc5f963aad0d.tar.gz
syndamia.com-b2377649aded6e17bc9c5aff60eafc5f963aad0d.zip
Parent440d2fac77f2293bd40bb4b3f330eb7e86b7b7bf (diff)
[blog/seoc] Rewording
1 files changed, 5 insertions, 5 deletions
-rw-r--r--src/blog/sane-explanation-of-compilers/part-1.md10
diff --git a/src/blog/sane-explanation-of-compilers/part-1.md b/src/blog/sane-explanation-of-compilers/part-1.md
index da1b718..6dd80af 100644
--- a/src/blog/sane-explanation-of-compilers/part-1.md
+++ b/src/blog/sane-explanation-of-compilers/part-1.md
@@ -19,7 +19,7 @@
3. [Implementing a front-end](#implementing-a-front-end)
1. [lex](#lex)
2. [yacc](#yacc)
- 3. [Using them together](#using-them-together)
+ 3. [Doing it properly](#doing-it-properly)
3. [Appendinx](#appendix)
Recently I signed up for a small university course about compilers.
@@ -1027,7 +1027,7 @@ gcc lex.yy.c parse.tab.c -lfl
Now when you run `./a.out`, if you enter a valid string, you'll see a blank line, but if it isn't valid, you'll get "Error: syntax error".
-#### Making a proper front-end
+#### Doing it properly
The way we created that lexer and parser worked, but it wasn't very useful and has multiple issues we have to address:
@@ -1099,7 +1099,7 @@ The way we created that lexer and parser worked, but it wasn't very useful and h
Another option is duplicating our `expr` rules and adding `expr` in the beginning or end, but that is cumbersome if we want to make changes.
4. We're getting input from the user, but our source text (code) will be in a file.
- First, our `main` function need to take program parameters:
+ First, our `main` function needs to take program parameters:
```yacc
int main(int argc, char* argv[])
@@ -1366,7 +1366,7 @@ Originally I planned to put everything in one blogpost, but writing the front-en
Additionally, while doing research, I found out the course actually skipped over a lot of important topics, which I'll first need to research.
Future parts will be linked right below the title at the very top, but it will probably be quite a while until I write them.
-I want to thank [Dimitar Tagarev](https://github.com/dtagarev) for his review and feedback on drafts of this post.
+Many thanks to [Dimitar Tagarev](https://github.com/dtagarev) for his help with reviewing this post.
[^how-did-we-get-here]: Though it's obvious, I would like to point out that modern compilers are most often written in languages that are themselves compiled. You might ask yourself "where did the first compiler come from?" The answer is simple: it was written with "numbers", with direct instructions to the processor, from the time when computers were simple enough that *all* programming was done with CPU instructions.
@@ -1384,4 +1384,4 @@ I want to thank [Dimitar Tagarev](https://github.com/dtagarev) for his review an
[^shift-reduce-conflicts]: You might be tempted to try and make one for the grammar inside the [AST](#abstract-syntax-tree) section, but that one is ever so slightly problematic, because it's ambiguous (I showed why at the end of [Implementational difficulties with grammars](#implementational-difficulties-with-grammars)). Bison [can handle ambiguity by always choosing to shift](https://www.gnu.org/software/bison/manual/html_node/Shift_002fReduce.html), but I didn't want to complicate things.
-[^better-yacc-errors]: You can add `%define parse.error verbose` inside definitions of your yacc file, and it will tell you what character was expected and what character was read.
+[^better-bison-errors]: You can add `%define parse.error verbose` inside definitions of your yacc file, and it will tell you what character was expected and what character was read.