Write better parsers with Nom Supreme

[@TonyAlvesDev]

Chris, this video with the GitHub example code is so great for being able to have examples for later. Thanks for all the content. These are going to be gold when I get to needing a parser.

[@DucBanal]

I must say that even though think nom is a really great library I have this feel that it is not Rustic because it does not use "the" postfix way. At the same time, I would like to temper the "it should only be this way" feel. Having the choice is nice ! Will keep nom-supreme in mind !

[@EngineerNick]

Thank you for the video :) I tried making a PEG parser in rust (like pegjs) and it was going well until i realized that PEG parser optimization is a rabbit hole, and also error reporting is very hard. Nom looks much easier

[@ArpegiusWhooves]

Yeah PEG are difficult, so I prefer LR and there is Lalrpop. I used it to solve last Advent of Code and for me it was easier then understand Chris videos. It has decent error reporting but totally do not want to work with Miette.

[@EthanSkowronski]

Nom Supreme is the first thing to make me seriously consider using Nom. Nom, as it's written, is a travesty of verbosity and inversion. Nom Supreme leans much more toward self documenting code -- much love

[@irlshrek]

such good timing! this is exactly what I needed

[@dj-maxus]

nom_supreme is exactly what I need to work with nom conveniently I am currently solving "Advent of Code 2022" and also was impressed by the power of nom presented in your videos on the advent. But nom's syntax looked non-idiomatic for Rust development, kinda odd. This is less relevant to nom_supreme, which is much more comfortable

[@chrisbiscardi]

yeah, I quite enjoy nom even without supreme's postfix extensions, but a lot of people seem to have similar feelings about the syntax used for the parsers so I'm happy it exists. how is advent of code going so far for you?

[@dj-maxus]

@@chrisbiscardi thanks for asking! Actually, it goes pretty well, but input parsing is the most difficult for me! 😭😂 For example, I implemented the solver of day 5's problem pretty easily in the part where input is already parsed into data structures. But it was hard without nom to connect the wire from the input side to that solver For me, this is an opportunity to write more working Rust code and get used to Helix editor as well (console editors are somewhat new to me)

[@chrisbiscardi]

@@dj-maxus totally get that. Glad its going well for you! I haven't used Helix yet. Should check it out one day.

[@JeffHanke]

@@dj-maxus How are you liking Helix? I will probably switch to it eventually, right now I'm using kakoune.

[@programjm]

Would be interested in hearing your thoughts on chumsky

[@ilonachan]

uhm hello, just dug up my old project beginnings where I had trouble finding the right parser library, and just now this video drops? are you in my walls?? I'm definitely gonna try this, thanks for sharing!

[@yellowajah]

Does nom_supreme affect performance at all?

[@chrisbiscardi]

The core nom crate (in the error handling doc: github.com/rust-bakery/nom/blob/bf8cddbdbdf768a2128b7817c4670da059351f9f/doc/error_management.md) mentions that the error system is flexible partially for performance reasons. For example: collecting/handling more errors and context can lead to lower performance for extremely high performance parsers, so I'd expect that in that case that ErrorTree would cost some performance over using nom::Error. This won't matter unless the scale of your application of a nom parser is pretty high though. As always, benchmarking your specific use case is the best solution to knowing if there's a relevant performance difference.

[@jackn]

great video! can i request a video on logging? i want to know rust best practices for logging to stdout, file logging, and json logging

[@chrisbiscardi]

I'll put it on the list. The tldr is "use the tracing crate"

[@el_carbonara]

thanks, was about to give up on nom til I found this. I find it unusable without chaining, seems like a huge design mistake. Even with this supreme lib it seems like you can only chain certain combinators and its honestly not clear to me what goes with what so I get huge type errors and give up. Overall I find nom a huge PITA to use but thats just my initial experience.

[@DeathSugar]

It's kinda sad that folk use default hex color parser but not something more complex, like whole css property

[@chrisbiscardi]

It's a constrained example to show the parser capabilities. You could use palette or lightningcss and it's underlying cssparser crates for production color use cases.

[@DeathSugar]

@@chrisbiscardi the thing is when you try to use them parsers for something more complicated and raises a bunch of questions which not obvious sometimes and not exist in such basic example - how one should eat spaces; how to manage cases, how to work with paired symbols like braces and quotes. Even idea of combinations poorly presented in the documentations. But everyone says "the X parser is great/better" without actually showing why is it actually great/better. I understand the video title should be clickbait, but this one didn't even close to explain. Is it because of how great error tree is?

[@chrisbiscardi]

@@DeathSugar yes, its literally because of the reasons I talk about in the video, such as ErrorTree. The title is not clickbait, nom supreme is a set of extensions to nom that enable you to write better parsers and I cover how and why in the video. nom has functions for spaces (multispace, space, etc), case handling (tag_no_case, alpha), and paired symbols (delimited) that work exactly the same as the parsers talked about in the video. The point of the video can't be to enumerate every function in the crate and you shouldn't expect it to. If you're looking for a list of all the documented functions, check out this link which will be closer to that: github.com/rust-bakery/nom/blob/1c1e9c896bd422baa8ae0a167be57ae721f10377/doc/choosing_a_combinator.md