Oh man, I'm so close to having this fold_many implementation working. I'm tripping up on some lifetime stuff.
let (input, init) = operand(input)?;
fold_many0(
preceded(
tag("&"),
cut(specific(Specific::ExpectAndExpression, operand)),
),
||init, // Lifetime error here
|a, b| Token::And(Box::new(a), Box::new(b)),
)(input)
yeah that's a frequent pain point with nom's combinators, even if you only need the resultant parser once, the combinator still needs to return a "FnNonOnce", so all inputs need to be
Clone/"FnNonOnce"
Sadly that's using i64, so it's copy and cloneable
Specifically for use in the fold functions. It's just a shame as it's extra boilerplate
You're going to vomit
fn and_term<'a, E>(input: &'a str) -> IResult<&'a str, Token, E>
where
E: nom::error::ParseError<&'a str> + SpecificError<&'a str>,
{
let (input, init) = term_or_not_term(input)?;
let (input, mut root) = fold_many0(
preceded(
ws_tag("&"),
cut(specific(Specific::ExpectAndExpression, term_or_not_term)),
),
|| Token::Bool(true),
|a, b| Token::And(Box::new(a), Box::new(b)),
)(input)?;
// Well well well, what is this hot mess?
// Because the left side is always either And or Bool, we can
// simply loop until we find the bool then replace it with init
//
// #NOTE This is necessary because it's not possible to move
// init into the closures passed to fold_many0 as they expect
// FnMut, not FnOnce
let mut t = &mut root;
while let Token::And(a, _) = t {
t = a.as_mut();
}
debug_assert!(matches!(t, Token::Bool(_)));
*t = init;
Ok((input, root))
}
This passes the tests, but it's so dirty
@AWildAudioNerd_twitter: I'd try
let init = Some(init) outside and || init.take().unwrap() as the initializing closure.
Sorry, I missed these details :-) the basic idea here is to be explicit: "take the ownership the first time the closure is called; you're free to panic if it's called again"
The option allows the ownership transfer to be explicit. If the closure were to be called again (which it won't in this instance), the option would be None and the method would panic
Ok, that's also dirty. But it's less dirty than my implementation.
Thank you! You folks have helped me level up in Rust during this process too
hello, any nom_locate users? i have trouble wrapping my mind around the error i am getting...
Original &str input parser:
type MyResult<'a, T> = nom::IResult<&str, T>;
fn yang_version_arg(input: &str) -> MyResult<&str> {
tag("1.1")(input)
}seems to work fine...
Then i try to use nom_locate and follow the gitbuh readme with Span 'type':
type MyResult<'a, T> = nom::IResult<Span<'a>, T>;
fn yang_version_arg(input: Span) -> MyResult<&str> {
tag("1.1")(input)
}but i get errors across whole app codebase wherever i try to use any nom combinator/parser:
error[E0308]: mismatched types
--> src\parser\rfc7950\yang_version_stmt.rs:29:5
|
28 | fn yang_version_arg(input: Span) -> MyResult<&str> {
| -------------- expected `Result<(LocatedSpan<&str>, &str), nom::Err<nom::error::Error<LocatedSpan<&str>>>>` because of return type
29 | tag("1.1")(input)
| ^^^^^^^^^^^^^^^^^ expected `&str`, found struct `LocatedSpan`
|
= note: expected enum `Result<(LocatedSpan<&str>, &str), nom::Err<nom::error::Error<LocatedSpan<&str>>>>`
found enum `Result<(LocatedSpan<&str>, LocatedSpan<&str>), nom::Err<_>>`do i miss some piece of puzzle? isn't some deref supposed to happen to allow usage of all pre-build combinators in nom?
Looks like
tag here returns LocatedSpan<&str> instead of &str, you may want to change the return type or convert it somehow.
I'd guess
tag and take are a special case here because their input and output are the same type?..
please excuse possibly stupid query, but, i seem to be beaten a bit by the error handling... is it possible to create/return explicitly some trivial error, no custom error implementaitons? in the combinator/parser code... all the examples keep showing custom structs/implementations, etc., i just want to plainly fail with no custom message, or, worst case, simple &str msg...
in the code, when all goes ok, i can simply do
Ok(rest, someval), but i fail to comperehend how to do the opposite -> Err(???), i may be dumbed down after hours or related experiments, but i fail to find the easy/short way on what to put into Err() enum for IResult<> not to complain about some types/fn-s,/etc.
If your code is generic over error types, there's
ParseError::from_error_kind
Yeah, there are a couple levels of wrapping here - you probably want
Err(nom::Err::Error(Error::new(...)))
what is idiomatic way to change failure of combinator to success if it happens (but still keep original success path)?
regular match ok/err on combinator result, or is there some wrapper combinator? none of the ones mentioned in "choosing combinators' seems to fit scenario directly
regular match ok/err on combinator result, or is there some wrapper combinator? none of the ones mentioned in "choosing combinators' seems to fit scenario directly
so you want the combinator to succeed unconditionally? what's your use case for this?
just from a type compatibility standpoint, that's
opt()
Hey folks! What's the proper way to do the equivalent of
I have
delimited(start, content, end)that includes both start and end in the final output?I have
delimited(char('['), is_not("]"), char(']'))("[::1]") that returns ("", "::1")but I would like it to return [::1] instead (without having to format! the output if possible)
I'd like it to return the str including the last character if it exists
I don't know if it's helpful, but I've typed up some pseudo-code for what I'm trying to do: https://gist.github.com/rust-play/3a8121101770f0ee5e76847fccf8f684 . Rather than an ad-hoc parser, I like the structured nom approach, but I'm not sure how to describe this type of streaming parser. Does anyone have examples for similar problems?
rather phylosophical question... when parsing an input according to some/a grammar, did you ever find it useful to "delay" the statement count restrictions to higher level/AST? e.g. for batch error identification, not to interrupt parser on first problem occurence? (forcing the user to re-iterate with each input parsed text fixes again and again before he progressively encounters all the errors)
1 reply