 Maurice Makaay
|
e3e408dfdb
|
Phew, that was quite the update. I've now got a working implementation of a parser/combinator-like matching API, which prevents us from having to specify everything in state functions. That is way too low level for a lot of things. I'd rather have parser/combinator-style definitions for chunks of the input and keeping the state functions for higher level document structure parsing.
|
2019-05-19 23:35:03 +00:00 |
|
Maurice Makaay
|
55e23874f7
|
Hmm... even beter wording! Fully from the parser writer's perspective, hiding internals.
|
2019-05-18 13:21:56 +00:00 |
|
Maurice Makaay
|
4556520582
|
Added some more straightforwardness to the pattern magic coding. I can now write stuff like p.After(upper, upper, 4hex).Store() to store runes in the string buffer when the match is complete. Other options instead of Store() are for now Backup() (making it more of a peek) or Ignore() (skipping over the scanned text). I think this methodology forms a nice mental representation for the coder that uses the library. It's close to how we think about parsing (or at least I do)
|
2019-05-18 01:19:25 +00:00 |
|
Maurice Makaay
|
666cff3af3
|
Ahhhh found a name that clicked for the more general layer of the parser code: parsekit. That is short and tells me what it is. It's not a parser, but something to build parsers with. Now I could also name the actual parsing code as I would like to, namely 'toml/parser'. So it feels like the structure is settling down.
|
2019-05-17 22:03:10 +00:00 |