Write about reader implementation in development log
This commit is contained in:
1 parent
b8c30cd225
commit
66c24de9e9
1 file changed
+29
@@ -73,3 +73,32 @@ provided in the base language, which is convenient for doing TDD.
|
|||||||
### LLM / AI Usage
|
### LLM / AI Usage
|
||||||
|
|
||||||
I will not be using any LLM coding assistants for this project.
|
I will not be using any LLM coding assistants for this project.
|
||||||
|
|
||||||
|
## Reader
|
||||||
|
|
||||||
|
### Lexer
|
||||||
|
|
||||||
|
I first implemented the lexer with a very simple finite state machine
|
||||||
|
consisting of two states, `Init` and `Integer`. This was
|
||||||
|
straightforward as the input language is very simple.
|
||||||
|
|
||||||
|
### Parser
|
||||||
|
|
||||||
|
Since the input grammar consists of terms, parentheses and infix
|
||||||
|
operators with varying precedence, Pratt parsing is the logical choice
|
||||||
|
for the implementation of a parser.
|
||||||
|
|
||||||
|
I find the usual way of handling associativity in precedence climbing
|
||||||
|
parsers (wherein a small amount is added to the binding power on one
|
||||||
|
side) somewhat inelegant, so I decided to implement a simple algebra
|
||||||
|
for binding powers that handles associativity using custom comparison
|
||||||
|
semantics.
|
||||||
|
|
||||||
|
Implementing the parser itself was straightforward as I have
|
||||||
|
implemented Pratt parsing many times before (though not in Rust
|
||||||
|
specifically).
|
||||||
|
|
||||||
|
To tie together the lexer and parser, and to provide a convenient
|
||||||
|
means of decoupling other components from them for testing purposes, I
|
||||||
|
then implemented the Rust standard library's `FromStr` trait, which is
|
||||||
|
for types that can be parsed from a string.
|
||||||
Reference in new issue
Block a user