Skip to content
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

In Context-0.2, try and simplify grammar walking order #424

Open
Yoric opened this issue Aug 23, 2019 · 3 comments
Open

In Context-0.2, try and simplify grammar walking order #424

Yoric opened this issue Aug 23, 2019 · 3 comments

Comments

@Yoric
Copy link
Collaborator

Yoric commented Aug 23, 2019

The grammar walking order in Context 0.1 is a bit complicated: it combines two depth-first strategies and implementing it properly seems to require two stacks. There is probably a simpler order that we could adopt (either breadth first or depth first or by need).

@acomminos
Copy link

Are you referring to needing to traverse the models section differently than the AST?

The root AST decoder we wrote for the V8 implementation uses a fairly simple DFS traversal in IDL/field order, and shouldn't require two stacks.

@Yoric
Copy link
Collaborator Author

Yoric commented Aug 24, 2019

Well, according to Dominic's document, it's definitely not a simple DFS.

I'll use the word "enqueue" because "push" is overloaded in both Dominic's document and the Python implementation.

  • When we visit an Interface, we enqueue all the fields that are not arrays (stack 1).
  • Whenever we encounter a field that is an array, we need to handle the length, then recurse immediately to the contents of the array (stack 2), before proceeding with stack 1.
  • Also, depending on the path/stack, the moment at which we check whether a table has already been visited is not the same.

Did you find a way to merge stack 1 and stack 2? If my memory serves, in the Python implementation, stack 2 is hidden by the Python stack, but that's not a good practice in production code, at least for a browser, as it it makes it hard to fail softly in case memory is exceeded. Here, grammars are simple, so both stacks are always relatively small, but that's generally a risk that we want to avoid (and it might even get rejected in future versions of Firefox by the static checker).

@Yoric
Copy link
Collaborator Author

Yoric commented Aug 26, 2019

Ideally, I'd prefer a way to load the tables without needing to walk the grammar itself, as this is some fairly heavy machinery.

In previous versions of the format, we had a convention that tables were written in the order in which they were needed for reading. This makes reading the prelude much simpler (and theoretically easier to parallelize with reading the contents), but doesn't scale well towards laziness.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants