[blog/seoc] Renamed title and finished parsing algorithms section

1 files changed, 13 insertions, 6 deletions

diff --git a/src/blog/sane-explanation-of-compilers-and-lex-yacc/index.md b/src/blog/sane-explanation-of-compilers/index.md
index 9a551eb..bfd4eeb 100644
--- a/src/blog/sane-explanation-of-compilers-and-lex-yacc/index.md
+++ b/src/blog/sane-explanation-of-compilers/index.md
@@ -1,4 +1,4 @@
-# Sane explanation of compilers and lex+yacc
+# Sane explanation of compilers
 
 ## Contents
 
@@ -365,9 +365,9 @@ The advantage and disadvantages of every type kind of depend on the exact algori
 Looking at some of the more famous ones:
 
 1. [LL](https://en.wikipedia.org/wiki/LL_parser): top-down left-most derivations algorithm that can parse only specific types of grammars.
-   In these grammar, every expression is uniquely identifiable by just looking at the characters (tokens) in the very beginning.
-   If an LL(k) algorithm can parse the given grammar, we say the grammar is a "LL(k) grammar".
-   An "LL(k)" grammar, by extension, is any grammar where each expression is uniquely identifiable by just looking at the first k tokens.  
+   In these grammars, every expression is uniquely identifiable by just looking at the characters (tokens) in the very beginning.
+   The amount of token we need to look for is very important, so we usually define LL(k) as an LL grammar that needs to look at k amount of tokens.
+   An "LL(k) grammar" is, by extension, a grammar which can be parsed with an LL(k) parser.  
    As an example, the grammar:
 
    ```grammar
@@ -395,12 +395,19 @@ Looking at some of the more famous ones:
    However if we look at the third symbol, "b", then we can determine that we need `aaB`.
 
 2. [LR](https://en.wikipedia.org/wiki/LR_parser): bottom-up right-most derivations algorithm.
-   It is slightly reminiscent to LL, parsing only specific grammars and needing to peek forward (lookahead; which also means LR(k) is similarly defined), but is significantly more powerful.
+   Also parses only specific grammars and needs to peek forward (lookahead; which also means LR(k) is similarly defined), but is significantly more powerful.
    However, the "normal" LR parser requires a lot of memory, which spurred it's variations - the [SLR](https://en.wikipedia.org/wiki/Simple_LR_parser), [CLR](https://en.wikipedia.org/wiki/Canonical_LR_parser) and most importantly:
 
-3. [LALR](https://en.wikipedia.org/wiki/LALR_parser)  
+3. [LALR](https://en.wikipedia.org/wiki/LALR_parser).
    These memory optimizations, however, came at a cost: lower grammar parsing power, though LALR can work with the most grammars out of all the alternatives and still beats LL.
 
+Unfortunately, these algorithms are way out of my area of knowledge, and furthermore a lot of parsers are custom-tailored for their language.
+If you want to dive deeper, I would suggest:
+
+- [LL and LR Parsing Demystified](https://blog.reverberate.org/2013/07/ll-and-lr-parsing-demystified.html) and [LL and LR in Context: Why Parsing Tools Are Hard](https://blog.reverberate.org/2013/09/ll-and-lr-in-context-why-parsing-tools.html) by [Josh Haberman](https://blog.reverberate.org/about/)
+- [Which Parsing Approach?](https://tratt.net/laurie/blog/2020/which_parsing_approach.html) by [Laurence Tratt](https://tratt.net/laurie/)
+- [A Guide to Parsing: Algorithms and Terminology](https://tomassetti.me/guide-parsing-algorithms-terminology/) by [Gabriele Tomassetti](https://inre.me/)
+
 #### Abstract syntax tree
 
 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.