Reproachfully Presenting Resilient Recursive Descent Parsing

Posted by thunderseethe@reddit | programming | View on Reddit | 5 comments

[-]

ToaruBaka@reddit

I think you have a typo in the expect code snippet, should this Continue be a Break? The ate function returns Break on a matched token.

fn expect(&mut self, token: Syntax, mut anchor_set: HashSet<Syntax>) {
  let ControlFlow::Continue(_) = self.ate(token) else {
    return;
  };

  // We didn't see the token we expected
}

Good article so far, I'll finish the back half after lunch.

[-]

Thanks for checking it out! This code is working as intended albeit it sound like it's not very clear. The next part of expect after this let..else is error reporting, which we only want to do if ate didn't see the expected token.

When ate sees the correct token and returns break that causes our let else to return early and we dont do any error recovery, since we saw the expected token. Conversely, when ate does not see the right token it returns Continue which causes expect to drop down and begin error recovery.

I think seeing the let Continue is probably confusing as the magic is all in the else which is implied to be taken on the break branch. I'll try making it an if let and see if thats clearer.

[-]

ToaruBaka@reddit

Ohhh I see, I missed the else at the end of the line - the updated version is more clear, thanks!

I think seeing the let Continue is probably confusing as the magic is all in the else which is implied to be taken on the break branch.

Yeah, I think that particular idiom (let-else-return) is easy to misread when paired with ControlFlow, because (at least for me) I was thinking about continue/break semantics, not if/else (the else without if is what really did me in, I think).

The explicit if version is much clearer IMO.

[-]

thunderseethe@reddit (OP)

Great! Im glad it helped. i appreciate you pointing it out. I write a lot of swift, where guard let ... else is idiomatic, so I have a blindspot for it in rust

[-]

ToaruBaka@reddit

There's nothing wrong per-say with let-else[-return] - it's super powerful and used all over the place. I do the same in Zig for const x = foo() catch return; and const x = y orelse return; for try/catch and optional unwrapping. Here it's moreso about the intersection of multiple control flow models.

Nice article - it was really helpful to see a fleshed out parser example that includes recovery. I was working on something a few months ago that would have benefited from a CST, so I'll be keeping that in my back pocket :)