Add `filter_map` I think

[jnhyatt]

This might be a skill issue, but I'm trying to create a lexer/parser combo, my tokenizer sees 1234 and spits out Token::Number(BigUint). Then I want my parser to see '-'? Number and spit out a Ast::Literal(BigInt). What should my parser look like? My first instinct was something like:

just(Token::Neg).or_not()
    .then(any().filter(|tok| matches!(tok, Token::Number(_))))
    .map(|(neg, num)| {
        // Uh-oh, num is a Token::Number guaranteed, but I have to do something nasty like:
        let number = match num { Token::Number(x) => x, _ => unreachable!() };
        ...
    })

When I hit situations like this with Iterators, I reach for filter_map:

just(Token::Neg).or_not()
    .then(any().filter_map(|tok| match tok { Token::Number(x) => Some(x), _ => None }))
    .map(|(neg, num)| {
        // Yay, num is a BigUint!
        ...
    })

I can't find that particular combinator in chumsky. Am I missing it, or is it an oversight, or maybe it's not as simple as it looks? Or best of all, maybe there's a simpler way to do what I'm trying to do here? I suppose there's select...

[Zij-IT]

I believe you are looking for chumsky::prelude::select (:

just(Token::Neg).or_not()
    .then(select!(Token::Number(num) => num))
    .map(|(neg, num)| {
        if neg.is_some() {
            Ast::Num(-num)
        } else {
            Ast::Num(num)
        }
    })

[jnhyatt]

Ah ok that makes sense, thanks. I still feel like filter_map is worth adding because:

• It's paralleled in the Iterator API
• It doesn't use macros
  Admittedly the second point might be controversial, but I typically don't like relying on macros because they can make some language server features grumpy, and it's not always trivial to inline them. In other words: mumble mumble Rust macros bad.

In all seriousness, I'd be happy to PR this if it's a desired feature, otherwise feel free to close this out.

[jnhyatt]

On second thought, primitive::select looks like filter_map, just named differently. This seems like it'd be a trivial change, but once again, I'd consider it useful simply for parity with Iterator.

[zesterer]

I would be happy to see filter_map introduced, if anybody is interested in working on it. Behaviourally, it's strictly more useful than select! since it applies to any parser's output, not simply a single token of input.

We have try_map which can in practice be used for the same thing, but it's a little bit more noisy to use.