Our great sponsors
-
zig
General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
Interesting read, especially as someone poking w/ writing a parser for fun in zig :)
One area of improvement worth mentioning in this area is that currently zig errors cannot be tagged with extra information, which tends to be important for surfacing things like line numbers in parsing errors. There was a proposal[0] to improve this and it's not the end of the world (as a workaround, I'm toying with returning error tokens similar to what treesitter does)
On a different node, there's another cool zig thing I found recently that is mildly related to parsing: a common thing in parsers is mapping a parsed string to some pre-specified token type (e.g. the string `"if"` maps to an enum value `.if` or some such so you can later `switch` over it efficiently). The normal way to avoid O(n) linear search over the keyword space is to use a hashmap (naively, one would use a runtime std.StringHashMap in zig). But I found an article from Andrew[0] about a comptime hashmap where a perfect hashing strategy is computed at comptime since we already know the search space ahead of time! Really neat stuff.
[0] https://github.com/ziglang/zig/issues/2647
[1] https://andrewkelley.me/post/string-matching-comptime-perfec...
Another interesting parser combinator written in Zig is Mecha. It works at comptime but it has to deal with the fact that it cannot allocate memory.
https://github.com/Hejsil/mecha
Understood, this helped me a lot, thank you. I definitely had confusion around DFA/NFA being a _type of regex engine implementation_ and see now why that is incorrect.
I updated the article[0] so as to hopefully not confuse others, really appreciate you taking the time to respond to me again, and sorry for not understanding your earlier comment :)
[0] https://github.com/hexops/devlog/commit/0159b510556c2943cbca...
Awesome app. Do you plan on using it for anything in particular? Or are you just creating it as a passion project. It's totally cool.
Learning about https://treenotation.org/ (linking this for other people, not for you, Breck :P), and I like what I see. My first impression was "Lisp, but with python indenting"
> We no longer need to store our data in error prone CSV, XML, or JSON. Tree Notation gives us a simpler, more powerful encoding for data with lots of new advanced features
This is the one thing I didn't understand! Tree notation seems equivalent to these. Like at a certain level, it's all just data. Now, the major benefit is that you're supposed to think differently about what you're doing when using tree notation. Would love to hear your opinion about this conjecture.
Zig is, very roughly speaking, competing with the C language. We might say that Zig is to C what Rust is to C++, again, very very roughly.
There's at least one Zig HTTP server framework out there [0] but it's not really what the language is intended for.
[0] https://github.com/frmdstryr/zhp