4 ms·

Shouldn't the title better by "Pest - Fast, modern parser _in_ Rust"? The current title made me think that this would be a Rust AST parser, similar to syntex.

grimgrin 9y ago
Yes this is no doubt the current implication. I was expecting something like racer.
reificator 9y ago
Exactly what I came into this thread expecting. Was curious why when it looks like there's already great IDE support for Rust with existing tools.
- dikaiosune 9y ago
  There's actually a parser for rust called syn, and it's very useful for procedural macros, as the current API exposes a stream of tokens, not a full AST.
  - steveklabnik 9y ago
    To elaborate a bit on that, exposing an AST directly means that you're tied to that version of the AST; this was considered really hard for compatibility over versions. Token streams are much easier to define an interface for, and more flexible: you're not just stuck with whatever AST representation we'd have given you. For example: https://doc.rust-lang.org/book/first-edition/procedural-macros.html https://doc.rust-lang.org/book/first-edition/procedural-macr...
dragostis 9y ago
I agree. I guess I was trying hard to suggest the fact that it can be used _with_ Rust and not the fact that it is written _in_ Rust.
z1mm32m4n 9y ago
The confusion here is because Pest is not, in fact, a parser. It's a parser generator: you can use it to generate parsers (maybe even a parser for Rust), but it is not in itself a parser. A better title would be "Pest - Fast, modern parser generator for Rust". One cool thing is that rather than the parser generation being a standalone tool, it's written using Rust's macro system. Normal parser generators use some sort of command line tool to generate say C code which can then be used like any other library. Here, there's no need for generated code, because the Rust macro system generates it on the fly.
dang 9y ago
OK we've attempted to make a more accurate title above.

grimgrin 9y ago

Yes this is no doubt the current implication. I was expecting something like racer.

reificator 9y ago

Exactly what I came into this thread expecting. Was curious why when it looks like there's already great IDE support for Rust with existing tools.

dikaiosune 9y ago
There's actually a parser for rust called syn, and it's very useful for procedural macros, as the current API exposes a stream of tokens, not a full AST.
- steveklabnik 9y ago
  To elaborate a bit on that, exposing an AST directly means that you're tied to that version of the AST; this was considered really hard for compatibility over versions. Token streams are much easier to define an interface for, and more flexible: you're not just stuck with whatever AST representation we'd have given you. For example: https://doc.rust-lang.org/book/first-edition/procedural-macros.html https://doc.rust-lang.org/book/first-edition/procedural-macr...

dragostis 9y ago

I agree. I guess I was trying hard to suggest the fact that it can be used _with_ Rust and not the fact that it is written _in_ Rust.

z1mm32m4n 9y ago

The confusion here is because Pest is not, in fact, a parser. It's a parser generator: you can use it to generate parsers (maybe even a parser for Rust), but it is not in itself a parser. A better title would be "Pest - Fast, modern parser generator for Rust". One cool thing is that rather than the parser generation being a standalone tool, it's written using Rust's macro system. Normal parser generators use some sort of command line tool to generate say C code which can then be used like any other library. Here, there's no need for generated code, because the Rust macro system generates it on the fly.

dang 9y ago

OK we've attempted to make a more accurate title above.