-
Notifications
You must be signed in to change notification settings - Fork 287
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lane Table not quite correct? #851
Comments
At a quick glance, is this related to #768? |
Ah whoops, I see you just commented on that issue. Race-conditions... |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi @nikomatsakis (and other maintainers)
I wanted to ask about a weird observation that both, yours and Xin Chen's interpretation of Pager's lane table approach appear to exhibit.
Consider your explanation here:
It says that for the second example, the lane table would look like this:
However, shouldn't it be:
because if we trace back on S3 via an "e" back to S3, and then move forward in the automaton by an X (or Y), we will end up in a successor state of S3 which will introduce a
"c" and "d"
lookahead.on grammophone
And if we look at it from the DeRemer and Pennello relations based approach for calculating LALR lookaheads, we will notice that there's a lookback relation for each of the conflicting reductions in S3 to a successor state, which introduces "c" and "d" lookaheads as I've pointed out above.
This appears not to be an issue because the missing lookaheads depend on those that already exist in the table. So things kind of work out? But still, I'm wondering whether this is a critical bug that makes the algorithm not quite correct.
The text was updated successfully, but these errors were encountered: