Pain point when starting: what's the output of that parser?

[bew]

Hey @zesterer, I just started using chumsky yesterday for the adventofcode challenges (while learning Rust 😃 ), and I loooove it, it's really a joy to use once you grok it ❤️ ❤️ ❤️

I've seen that you're actively writing a tutorial @ https://github.com/zesterer/chumsky/blob/master/tutorial.md

You might be interested in this:

My main pain point when starting to use the lib was to understand what the output of a parser was.
For example at the beginning I tried to chain separated_by with a repeated which does not make sense for me, I didn't understand that separated_by's output was already a collection like a Vec..

I think it would help to explicitly mention what the output is whenever you write/document a parser.
👉 in the tutorial
👉 and maybe also in the documentation of each builtin parsers?

---

Another pain point are the errors that are near-impossible to read, like:

But I don't think you can do anything about this... (note: I've found my issue for that one)
Unless there's a way to write a kind of compiler plugin that could help decipher these looong types / make them prettier / easier to read ?

[zesterer]

Hey, thanks for the feedback! I'm glad to hear you're enjoying using the crate.

I've seen that you're actively writing a tutorial

Yup, it should be in a decent state now (enough to learn from, anyway).

My main pain point when starting to use the lib was to understand what the output of a parser was.

This is a good idea, I should be more explicit about this in documentation.

Another pain point are the errors that are near-impossible to read, like

As you mention, it's difficult to coerce the compiler into generating sensible errors. One thing I'm planning to do is to also add constraints to the methods on the Parser trait in an attempt to constrain the compiler's error messages a little more. Hopefully, the next release will include such improvements.

In general, the thing to do is to look only at the very first error message: this is the one that's the most likely to be correct.

[bew]

I continue here, not sure where I'd write this otherwise, there's no Matrix room or open communication channel, does it?

In the tutorial, at https://github.com/zesterer/chumsky/blob/master/tutorial.md#cleaning-up-and-taking-shortcuts
You're doing:

let int = text::int(10)
    .map(|s: String| Expr::Num(s.parse().unwrap()))
    .padded();

I've wondered, why you put the : String part in the args of map's closure?
Is this to make some kind of implicit conversion because the output of text::int is a Vec<char> ? (not sure)

The doc of text::int isn't very clear about it: https://docs.rs/chumsky/0.6.0/chumsky/text/fn.int.html
It says it's a Collection, and I don't understand how it gets transformed to a String for the map.

[zesterer]

Regarding output types: I've just updated the crate docs with more examples and the output type of every parser.

I've wondered, why you put the : String part in the args of map's closure?

Many of the parsers in the text module are generic across Unicode (via char) and ASCII (via u8) characters, including ident. The String is required to tell text::int that it should be parsing chars and not u8s. You could also swap out String with Vec<u8> if you wanted a parser that parses integers using ASCII bytes.

I've improved the docs for int (and others) so that this is a bit clearer.

[bew]

Thanks for the output-types doc update!

Makes sense now 👍

[zesterer]

As a point of interest, the following should also work:

let int = text::int::<char, _>(10)
    .map(|s| Expr::Num(s.parse().unwrap()))
    .padded();

[bew]

On the doc update commit, made a few comments, you saw a few of them, maybe you missed the other so in case, here they are:

• 86c0195#r61368107 on chain (you saw it)
• 86c0195#r61368632 on or (you saw it)
• 86c0195#r61368803 on empty (missed it?)
• 86c0195#r61368872 on take_until (you saw it)
• 86c0195#r61369490 on phrasing of none_of (missed it?)