FAQ
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.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Jan Mercl at Mar 5, 2015 at 9:28 pm

    On Thu, Mar 5, 2015 at 10:05 PM wrote:

    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.
    $ go get code.google.com/p/godeit/ebnflint2
    $ go get github.com/cznic/ebnf2y
    $ ebnflint2 -start SourceFile ~/go/doc/go_spec.html | ebnf2y -oe
    /dev/stdout -o /dev/null

    -j

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Thwd at Jun 25, 2015 at 10:54 am
    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?
    On Thursday, March 5, 2015 at 10:29:20 PM UTC+1, Jan Mercl wrote:

    On Thu, Mar 5, 2015 at 10:05 PM <alex....@gmail.com <javascript:>> wrote:

    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.
    $ go get code.google.com/p/godeit/ebnflint2
    $ go get github.com/cznic/ebnf2y
    $ ebnflint2 -start SourceFile ~/go/doc/go_spec.html | ebnf2y -oe
    /dev/stdout -o /dev/null

    -j
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jan Mercl at Jun 25, 2015 at 11:32 am

    On Thu, Jun 25, 2015 at 12:54 PM thwd 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].

    [0]: http://golang.org/ref/spec#Composite_literals
    [1]: https://go.googlesource.com/go/+/go1.4.2/src/cmd/gc/go.y
    [2]:
    https://github.com/cznic/tmp/blob/03d910b90fd960f00f52fc0b049b293e200b3d4c/gc/parser.y
    [3]:
    https://github.com/cznic/tmp/blob/03d910b90fd960f00f52fc0b049b293e200b3d4c/gc/lexer.go#L444

    --

    -j

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Brendan Tracey at Jun 25, 2015 at 12:10 pm

    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?

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Marvin Renich at Jun 25, 2015 at 12:22 pm

    * Brendan Tracey [150625 08:10]:

    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?
    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

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jan Mercl at Jun 25, 2015 at 12:33 pm

    On Thu, Jun 25, 2015 at 2:10 PM Brendan Tracey 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.

    [0]:
    https://github.com/golang/go/blob/52e9bcafe1b5bdae3354ddf82879751dfe6eb25b/src/cmd/gc/go.y#L594

    --

    -j

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Brendan Tracey at Jun 25, 2015 at 12:34 pm
    I see, thanks.
    On Jun 25, 2015, at 7:33 AM, Jan Mercl wrote:
    On Thu, Jun 25, 2015 at 2:10 PM Brendan Tracey 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.

    [0]: https://github.com/golang/go/blob/52e9bcafe1b5bdae3354ddf82879751dfe6eb25b/src/cmd/gc/go.y#L594 <https://github.com/golang/go/blob/52e9bcafe1b5bdae3354ddf82879751dfe6eb25b/src/cmd/gc/go.y#L594>

    --
    -j


    --
    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 <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+unsubscribe@googlegroups.com For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMar 5, '15 at 9:05p
activeJun 25, '15 at 12:34p
posts8
users5
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase