[HN Gopher] Zig, parser combinators, and why they're awesome
       ___________________________________________________________________
        
       Zig, parser combinators, and why they're awesome
        
       Author : todsacerdoti
       Score  : 65 points
       Date   : 2021-03-10 21:32 UTC (1 hours ago)
        
 (HTM) web link (devlog.hexops.com)
 (TXT) w3m dump (devlog.hexops.com)
        
       | unwind wrote:
       | Meta: the final word in the target page's title ("awesome") is
       | missing from the submission title. It becomes a little hard to
        
         | smoldesu wrote:
         | At first I didn't understand, but now I think I get
        
           | agumonkey wrote:
           | read it
        
         | dilap wrote:
         | I'm confused about "callconv(.Inline)" on the _function
         | pointer_. Isn 't a function pointer not inlinable by its very
         | nature?
        
         | Jtsummers wrote:
         | Whenever you make a submission, always check the title. The
         | automatic title editing from HN often makes sense, but not
         | always.
        
         | dang wrote:
         | We've made the title awesome again.
        
       | kristoff_it wrote:
       | Another interesting parser combinator written in Zig is Mecha.
       | 
       | https://github.com/Hejsil/mecha
        
         | slimsag wrote:
         | (author here) Mecha looks really nice!
         | 
         | One difference that makes Mecha's look really nice/simple is
         | they are being built at compile time, whereas the ones I
         | outline in this blog post are being built at runtime (with the
         | intention of later building parsers at runtime _based on other
         | parsers output_.
         | 
         | Or, at least that's what I gleaned from a quick skim of Mecha.
         | Very excited to play around with it soon!
        
           | kristoff_it wrote:
           | You got it right! I think it's nice to be able to contrast
           | the two implementations :)
        
       | lhorie wrote:
       | Interesting read, especially as someone poking w/ writing a
       | parser in zig for fun :)
       | 
       | 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 for me anyways (as a
       | workaround, I'm toying with returning error tokens similar to
       | what treesitter does)
       | 
       | On a different note, 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 pattern match tokens 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...
        
         | slimsag wrote:
         | Super interesting, thanks for sharing! I'd be curious to learn
         | more about how you workaround the lack of extra info in error
         | types in practice? Are you just returning e.g. a struct with
         | additional info?
        
         | kristoff_it wrote:
         | The comptime switch idea has been expanded into a full fledged
         | implementation in the standard library!
         | 
         | std.ComptimeStringMap
         | 
         | https://github.com/ziglang/zig/blob/master/lib/std/comptime_...
        
       | Koshkin wrote:
       | So... why are they awesome, again? Is this some kind of
       | functional approach to parsing? (I know that functions compose
       | very well.)
        
       | breck wrote:
       | I absolutely love parser combinators, and years ago I did a huge
       | rewrite of my compiler compiler so that it'd have the easiest
       | possible parser combinators: simple string concatenation.
       | grammarA + grammarB = grammarC. You can play with that here
       | (https://jtree.treenotation.org/designer/). You still need to
       | make a line change or two (good design after all, requires some
       | integration), but it just works. Haven't seen anything beat it
       | and not sure if that's possible. (Note: I do apologize for the
       | crappy UX, and it's high on the priority list to give the app a
       | refresh)
        
       | FnControlOption wrote:
       | I haven't dug into this yet, but the table of contents appears to
       | be broken.
        
         | slimsag wrote:
         | Author here, looks like I messed up one of the links by
         | accident. Should be fixed now :)
        
       | ncmncm wrote:
       | Zig is more capable than I thought.
       | 
       | It looks like there are definite plans to make it moreso, and
       | more interesting.
        
         | kristoff_it wrote:
         | The "more ergonomic C" crowd is missing some important nuance.
        
       ___________________________________________________________________
       (page generated 2021-03-10 23:00 UTC)