jorendorff / aoc-parse Goto Github PK

A regular expression can use a repeating * or + on a term that can match the empty string:

$ python3
Python 3.10.6 (main, Nov 14 2022, 16:10:14) [GCC 11.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> x = re.compile(r'()*')
>>> x.match("abc")
<re.Match object; span=(0, 0), match=''>
>>> _.group(1)
''

But aoc-parse has to build the vector of all matches, which it does by actually repeatedly matching the inner pattern against the string and appending results to a vector each time a match is found.

    #[test]
    fn test_repeat_empty_match() {
        let p = star(empty());
        assert_parse_eq(p, "", vec![]);
    }

This hangs trying to build the infinite vector vec![(); infinity]

Not sure what to do here. Reject the pattern? Make * ignore empty matches?

Is there any way to do non_capturing matching? For example:

parser!(lines(no_capture(any_char*) digit no_capture(any_char*)))

which would return a Vec<usize> of the first digit in each line.

@AlisCode writes:

My colleague and I are the original writers of aoc-runner, and we've noticed your recent release of aoc-parse. I personally love it, great work! I tried moving my parsing of this year's day 4 to it, and ended up with something like this :

#[derive(Debug)]
struct Assignment {
    one: RangeInclusive<usize>,
    two: RangeInclusive<usize>,
}

#[aoc_generator(day4)]
fn parse(input: &str) -> Vec<Assignment> {
    parser!(
        lines(
            a:usize "-" b:usize "," c:usize "-" d:usize
            => Assignment { one: (a..=b), two: (c..=d) }
        )
    )
    .parse(input)
    .unwrap()
}

I was slightly confused because it sounded to me like this should work, but I got an error saying the parser expected a \n and got an EOF instead. Reading the code, it does of course make sense : the "lines" parser fails as "incomplete" when the last line contains an EOF.

When using an automated tool such as cargo-aoc to retrieve your input, the lines parser won't work out of the box (e.g. my day 4 fails). Same thing happens when writing unit tests for the day's puzzle and copy-pasting things from the website to a static &str, e.g. for day 4 :

const INPUT: &'static str = "2-4,6-8
2-3,4-5
5-7,7-9
2-8,3-7
6-6,4-6
2-6,4-8"; // <- end of input here

Obviously I can fix this by adding a newline at the end of the input, and at the end of my downloaded input, but this doesn't feel like the right approach.

I do believe that the parsers should work out of the box when copy-pasting inputs, and I believe users of cargo-aoc, myself included, would be happy to add aoc-parse in their toolbox!

Do you see a different way of handling EOF that would make this work ?

This test fails to compile:

#[test]
fn test_mappers() {
    const SP: char = ' ';
    let p = parser!(a:u32 SP b:u32 => (a, b));

    assert_parse_eq(p, "31 54", (31, 54));
}

There is a mismatch between

• how SequenceParser decides how many elements the output tuple is going to have
• how the parser! macro builds the pattern for the closure arguments

In short, the two don't have the same information and do not agree, so the resulting code doesn't even compile.

The easiest fix is to have a dumber SequenceParser that always produces a pair, and use that when => is present.

The puzzle input for December 13, 2022 looks like this:

[1,1,3,1,1]
[1,1,5,1,1]

[[1],[2,3,4]]
[[1],4]

[9]
[[8,7,6]]

The lists can nest arbitrarily deep. aoc-parse needs new syntax to support this. Here's an attempt:

enum Value {
    Int(u32),
    List(Vec<Value>),
}

let value = parser!(
    rule value: Value = {
       n:u32 => Value::Int(n),
       "[]" => Value::List(vec![]),
       "[" vs:values "]" => Value::List(vs),
    };
    rule values: Vec<Value> = repeat_sep(value, ",");
    value
);

let p = parser!(sections(line(value) line(value)));

Ideally it would work without the type annotations, but that is probably impossible. I don't think Rust's type inference can handle it. In general, Rust makes you put types on things like fns that might be mutually recursive.

2017 day 21 contains two types of patterns. I'd like to be able to distinguish them at parsing. In regex, I'd do that with something like (.#){2}\/(.#){2} =>((.#){3}\/){2}(.#){3} for the 2x2 => 3x3 case. aoc-parse does not, as far as I know, have an equivalent.

I propose the same syntax with {}, as well as a repeat_sep_n(pattern, sep, n).

Note that simply writing the pattern n times doesn't work as nicely, since it returns a tuple.