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
|
||||
|
||||
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