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

Address possible ambiguities in grammar productions #2758

Open
IdanHo opened this issue Apr 29, 2022 · 4 comments
Open

Address possible ambiguities in grammar productions #2758

IdanHo opened this issue Apr 29, 2022 · 4 comments

Comments

@IdanHo
Copy link

IdanHo commented Apr 29, 2022

Following a discussion about a failing test262 test for the Temporal proposal in the LibJS engine due to a grammar ambiguity, it was raised that it's not immediately obvious from the specification text how possibly ambiguous grammar productions should be handled, e.g. are they inherently editorial errors, or, if they are not, which sub production should be prioritised? (by order in the sub-production list?)
This is especially important in the case of Temporal, as following the parsing the the specific sub productions are referenced and checked for existence, so such an ambiguity can result in a different conditional being taken.

Clarification on this would be appreciated. (And maybe we could also explicitly address it in the Syntactic and Lexical Grammars section of the specification text)


P.S. An example of a possible 'ambiguous' production - the following is ambiguous for the input of 1:

ExampleProduction:
	OctalDigit
	HexDigit
@bakkot
Copy link
Contributor

bakkot commented Apr 29, 2022

Ambiguous productions are inherently editorial errors (except for the RegExp grammar given in Annex B, which explicitly notes how ambiguities are broken).

I'm not totally sure it's worth writing that down in the spec itself, but we should at least document it alongside other editorial conventions somewhere.

@IdanHo
Copy link
Author

IdanHo commented Apr 29, 2022

Thanks for the swift response! I have no strong feelings about the location of the documentation, just one data point towards putting it in the specification itself is that as implementers we probably wouldn't have looked for editorial conventions when trying to understand this specific issue.

@ljharb
Copy link
Member

ljharb commented Apr 29, 2022

@IdanHo can you link to LibJS? Is it a new engine?

@IdanHo
Copy link
Author

IdanHo commented Apr 29, 2022

LibJS is SerenityOS's native from-scratch javascript engine (used in-tandem with LibWeb for Serenity's native browser), it is relatively new, work started in 2020.
The source code is available here: https://github.com/SerenityOS/serenity/tree/master/Userland/Libraries/LibJS
Automatically updated test262 results here: https://libjs.dev/test262/
And it's also supported by esvu.

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

3 participants