Re: Typescript grammar in Bison
Simon Richter <[email protected]> Wed, 23 Mar 2022 09:33:17 +0100
| Newsgroups | gmane.comp.parsers.bison.general |
|---|---|
| Message-ID | <[email protected]> |
Hi,
On 3/22/22 9:24 PM, Ricard Gascons wrote:
> I've been a Bison user for some time now, I've been writing some toy
> projects here and there. I was wondering if there are online resources I
> could find existing grammar from well-known programming languages? Just the
> definitions, not the implementations of course.
> More specifically, I'm looking for an existing Typescript grammar I could
> use for a personal project. I guess Javascript would work too. I've looked
> online and haven't had any luck so far.
I have a beginning of one that accepts the official ECMAScript testsuite
at least, but there is quite a lot missing both in the grammar and in
the testsuite.
The main problem with ECMAScript is that in principle it would be
possible to build an LALR parser for it, but there is no way to express
this sensibly in Bison, as the definition uses "negative tokens" and
last-resort parsing extensively.
The "continue", "break", "throw", "return" and "yield" statements have
an optional expression that can follow, but a newline is not permitted
at this point, likewise newlines are not permitted before the "=>" token
in an arrow-function.
This works together with automatic semicolon insertion to accept
programs with missing semicolons -- the rule is that if a token is
unexpected, but the parse would be valid if a semicolon was inserted
before the current token, then the parser should pretend that the
semicolon was there.
That can be expressed in some, but not all cases, e.g.:
lexical_declaration:
"let" binding_list ';'
| "let" binding_list
works for me, and I can generate a warning "inserted semicolon" from the
action of the second list, but this technique doesn't work everywhere a
semicolon is expected, because that introduces conflicts that are
technically in another rule, so precedence cannot resolve these.
Feel free to use the attached lexer and parser as a basis. The "NOLT"
comment indicates places where no line terminator is allowed, this is
currently not enforced.
Simon
es.ll.xz
(application/x-xz, 2.4 KB) - not displayed
es.yy.xz
(application/x-xz, 8.5 KB) - not displayed
OpenPGP_signature
(application/pgp-signature, 488 B) - not displayed