machine-parseable ebnf for go language?

280 views
Skip to first unread message

alex....@gmail.com

unread,
Mar 5, 2015, 4:05:56 PM3/5/15
to golan...@googlegroups.com
Is there a machine-parseable version of the golang EBNF from https://golang.org/ref/spec anywhere? Any format is fine, so long as it's consistent and complete. I could just copy the EBNF snippets from the spec into a file, but I thought I'd ask here to see if this is available elsewhere first.

Jan Mercl

unread,
Mar 5, 2015, 4:29:20 PM3/5/15
to golan...@googlegroups.com

$ ebnflint2 -start SourceFile ~/go/doc/go_spec.html | ebnf2y -oe /dev/stdout -o /dev/null

-j

thwd

unread,
Jun 25, 2015, 6:54:22 AM6/25/15
to golan...@googlegroups.com
Sorry to revive this relatively old thread. I'm wondering: is the grammar embedded in the spec actually sound and if yes, is it deterministic, unambiguous, left-recursive?

Jan Mercl

unread,
Jun 25, 2015, 7:32:19 AM6/25/15
to golan...@googlegroups.com
On Thu, Jun 25, 2015 at 12:54 PM thwd <sedevel...@gmail.com> wrote:

> Sorry to revive this relatively old thread. I'm wondering: is the grammar embedded in the spec actually sound

It's consistent, complete and grammatically correct.


> and if yes, is it deterministic,

No, b/c it's ambiguous.

> unambiguous,

No, b/c 
""""
A parsing ambiguity arises when a composite literal using the TypeName form of the LiteralType appears as an operand between the keyword and the opening brace of the block of an "if", "for", or "switch" statement, and the composite literal is not enclosed in parentheses, square brackets, or curly braces. In this rare case, the opening brace of the literal is erroneously parsed as the one introducing the block of statements. To resolve the ambiguity, the composite literal must appear within parentheses.
""""[0]

> left-recursive?

Yes.

A working yacc grammar exists in the current release[1], which, depends on some help from the lexer.

Alternative, slightly modified yacc grammar eg. at [2], using the same lexer tricks[3].


--

-j

Brendan Tracey

unread,
Jun 25, 2015, 8:10:02 AM6/25/15
to golan...@googlegroups.com


No, b/c 
""""
A parsing ambiguity arises when a composite literal using the TypeName form of the LiteralType appears as an operand between the keyword and the opening brace of the block of an "if", "for", or "switch" statement, and the composite literal is not enclosed in parentheses, square brackets, or curly braces. In this rare case, the opening brace of the literal is erroneously parsed as the one introducing the block of statements. To resolve the ambiguity, the composite literal must appear within parentheses.
""""[0]

The spec forces there to be parentheses. Doesn't this resolve the ambiguity?

Jan Mercl

unread,
Jun 25, 2015, 8:34:05 AM6/25/15
to golan...@googlegroups.com
On Thu, Jun 25, 2015 at 2:10 PM Brendan Tracey <tracey....@gmail.com> wrote:

> The spec forces there to be parentheses. Doesn't this resolve the ambiguity?

It does resolve the ambiguity of the yacc grammar. However, the yacc grammar no more matches the EBNF one. Left brace tokens are in certain places (eg[0]) replaced by a special token, which the lexer returns instead when certain conditions are met - and which is not present in the EBNF grammar.


--

-j

Brendan Tracey

unread,
Jun 25, 2015, 8:35:00 AM6/25/15
to Jan Mercl, golan...@googlegroups.com
I see, thanks.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/rpNiXhFMZMg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Marvin Renich

unread,
Jun 25, 2015, 8:23:07 AM6/25/15
to golan...@googlegroups.com
* Brendan Tracey <tracey....@gmail.com> [150625 08:10]:
Yes, but the question was whether the ebnf was unambiguous, not whether
the written spec was unambiguous. The ebnf requires additional English
words to disambiguate it.

...Marvin

Reply all
Reply to author
Forward
0 new messages