I like Markdown for its simplicity. Simplicity comes with limitations. There are some features that I miss in Markdown or it is possible to extend Markdown to support these cases, but there is no support from the Hugo side (static site generator I use).
Improve syntax highlighting Traditionally IDE (or text editors) use regular expressions to do syntax highlighting. This approach is limited in what is highlight correctly. They do it because:
it will work even for files with syntax errors it is faster than do real parsing on each keystroke (programming languages typically use context-free grammar) Tree-sitter uses incremental parsing, which allows it to do real parsing on each keystroke fast - it reparses only changed region of code and reuses parse tree from the previous parse for the rest.
Definition I would say that something is programming language (PL) if:
1: there is a machine that can do some actions (computations) based on the text written in the language (program) 2: or this language can be mechanically translated (compiled) to a programming language Now let’s see if we can tell based on this rule if something a PL or not.
Machine code? Yes, it can be interpreted by CPU Assembly?
When I tried to read papers on parsing algorithms I found a lot of terminologies (sometimes used inconsistently), a lot of abbreviations, and contradictory claims.
I decided to make some notes - write down definitions and abbreviations to understand papers.
Parser users tend to separate themselves into bottom-up and top-down tribes. Top-down users value the readability of recursive descent (RD) implementations of LL parsing along with the ease of semantic action incorporation. Bottom-up users value the extended parsing power of LR parsers, in particular the admissibility of left recursive grammars, although LR parsers cannot cope with hidden left recursion and even LR(0) parse tables can be exponential in the size of the grammar, while an LL parser is linear in the size of the grammar.