Return a result in PrattParser .map_primary

[Specy]

i'm using the PrattParser to parse an expression, i have some parsers that might return an error (for example in this case the parse_function_call checks for the number of arguments or if the function name exists) but the .map_primary, and the rest of the mapping functions, don't accept a result, how should i do it? or is this something that could be added to the pratt parser?

let parser = PrattParser::new()   
.op(
    Op::infix(Rule::add, Assoc::Left) | 
    Op::infix(Rule::sub, Assoc::Left) |
    Op::infix(Rule::div, Assoc::Left) |
    Op::infix(Rule::mul, Assoc::Left)
)
.op(Op::prefix(Rule::sub));

parser
.map_primary(|exp| {
    let span = InputSpan::from_pair(&exp);
    match exp.as_rule() {
        Rule::function => {
            let fn_call = parse_function_call(&exp)?; //<--- how?
            PreExp::FunctionCall(Spanned::new(fn_call , span))
        }
        _ => /*other rules...*/
    }
)

[tomtau]

@segeljakt I think this may be possible as what's returned by map_primary is generic over the return type: https://docs.rs/pest/latest/pest/pratt_parser/struct.PrattParserMap.html?

@Specy I think you can put Ok(PreExp::FunctionCall(Spanned::new(fn_call , span))) instead of PreExp::FunctionCall(Spanned::new(fn_call , span)) at the end (or wrap the whole match expression in Ok, I don't know how the rest looks like)?
You may also need to add some type annotations if the Rust compiler isn't be able to infer that T (of PrattParserMap) should be Result<PreExp...,...>

[Specy]

I had thought about that, but i think i misunderstood how i could have implemented it.
I thought after that i would need a "second pass" over the generated tree to flatten the results, but i just realized the fact that the result would just bubble up in the operator mapping, as if any of the two operands were a Err result, then i could just return an Err for that operator, and the final value will just be a Result<PreExp,...>
I'll try it out and update here if i got it to work! That way i can finally get rid of the crappy implementation i had made before PrattParser

[Specy]

Also unrelated to this topic, but is there a way i could allow the PrettParser to also parse implicit operands? things like 10x being treated as 10 * x
my other idea was to modify the rules by adding a Rule::mul in between any adjacent atoms, but i think at this point i could add this behavior to the grammar itself, defining the implicit multiplication as an { atom ~ atom } and in the map_primary check for this and emit a Binary operation, and since it's only allowed between atoms, precedence wouldn't matter i think (even in cases like 10(x + y) or (x+y)(x-y))
i tried and it doesn't seem to be that easy because of ambiguities

[Specy]

I tried that out and it worked flawlessly! Code is here.
The compiler also managed to infer the result type