FAQ
I'm a newbie of Go, from C language. When I wrote these code, the gc
compiler tells me:

"*syntax error: unexpected semicolon or newline before {*"

But in my code, there is no semicolon and no {. So I do not known what on
earth the compiler is talking about. Can you say it more clearly? thanks.

----------------------------------------------------------------
if (i == 0)
     i++ // syntax error?
----------------------------------------------------------------


--
by *Liigo*, http://blog.csdn.net/liigo/
Google+ https://plus.google.com/105597640837742873343/

--
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/groups/opt_out.

Search Discussions

  • Jesse McNelis at Jun 12, 2013 at 7:38 am

    On Wed, Jun 12, 2013 at 5:33 PM, Liigo Zhuang wrote:

    ----------------------------------------------------------------
    if (i == 0)
    i++ // syntax error?
    ----------------------------------------------------------------
    You want,
    if i == 0 {
       i++
    }

    The curly braces are required and the parenthese aren't required.
    I recommend you go through the tour before trying to guess the syntax.
    http://tour.golang.org

    --
    =====================
    http://jessta.id.au

    --
    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/groups/opt_out.
  • David Symonds at Jun 12, 2013 at 8:27 am
    It's a really bad compiler error message, but I echo Jesse's
    suggestion of taking the Go tour.

    I have filed https://code.google.com/p/go/issues/detail?id=5687 to
    improve the error message.

    --
    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/groups/opt_out.
  • Jan Mercl at Jun 12, 2013 at 8:44 am

    On Wed, Jun 12, 2013 at 10:27 AM, David Symonds wrote:
    It's a really bad compiler error message,
    The compiler sees ';' where '{' is expected. IMO the message is just
    fine. Also, no message can help someone who probably didn't ever read
    the specs or some reasonable amount of existing (valid) code. (I'm
    among those who cannot learn a language trough tutorials/tours/books
    etc.)

    -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/groups/opt_out.
  • David Symonds at Jun 12, 2013 at 8:56 am
    Like I said on the bug, *I* understand this, as do you, but we
    shouldn't require error messages for something relatively simple like
    this to be understandable to only someone who has read and understood
    subtle nuances in the spec or already knows the language well.

    If the error instead something like "missing {" on the line of the if
    statement, that would be much more helpful.

    --
    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/groups/opt_out.
  • Robert Melton at Jun 12, 2013 at 9:06 am

    On Wed, Jun 12, 2013 at 4:56 AM, David Symonds wrote:

    Like I said on the bug, *I* understand this, as do you, but we
    shouldn't require error messages for something relatively simple like
    this to be understandable to only someone who has read and understood
    subtle nuances in the spec or already knows the language well.
    Subtle nuances... really? That is basic Go syntax, and I don't think
    optimizing for it is any more logical than optimizing pythons handling of
    curly-braces.

    --
    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/groups/opt_out.
  • Jan Mercl at Jun 12, 2013 at 9:06 am

    On Wed, Jun 12, 2013 at 10:56 AM, David Symonds wrote:
    If the error instead something like "missing {" on the line of the if
    statement, that would be much more helpful.
    I agree that this message is probably more helpful. But I don't think
    it's correct. The semicolon injection rules are defined at the
    scanner/token stream level. At the language grammar level, however, no
    "on the same line" concept really exists. (Or matter. Nor it should.)

    -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/groups/opt_out.
  • Liigo Zhuang at Jun 12, 2013 at 11:34 pm
    the scanner/token is a part of gc program. the semicolon is inserted by gc
    and puzzled gc? IMO "insert semicolons" is compiler's internal
    implementation, and should not appear in language specs.
    在 2013-6-12 下午5:06,"Jan Mercl" <0xjnml@gmail.com>写道:
    On Wed, Jun 12, 2013 at 10:56 AM, David Symonds wrote:
    If the error instead something like "missing {" on the line of the if
    statement, that would be much more helpful.
    I agree that this message is probably more helpful. But I don't think
    it's correct. The semicolon injection rules are defined at the
    scanner/token stream level. At the language grammar level, however, no
    "on the same line" concept really exists. (Or matter. Nor it should.)

    -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/groups/opt_out.
  • Ian Lance Taylor at Jun 13, 2013 at 12:01 am

    On Wed, Jun 12, 2013 at 4:34 PM, Liigo Zhuang wrote:
    the scanner/token is a part of gc program. the semicolon is inserted by gc
    and puzzled gc? IMO "insert semicolons" is compiler's internal
    implementation, and should not appear in language specs.
    For what it's worth, though, It does appear in the language spec:
    http://golang.org/ref/spec#Semicolons .

    Ian

    --
    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/groups/opt_out.
  • Kevin Gillette at Jun 13, 2013 at 2:47 am
    The simplest way to describe lexical requirements is to put semicolon
    insertion rules in the spec (otherwise, there'd be too many additional spec
    rules to update and follow each time additional tokens are added).
    On Wednesday, June 12, 2013 5:34:00 PM UTC-6, Liigo Zhuang wrote:

    the scanner/token is a part of gc program. the semicolon is inserted by gc
    and puzzled gc? IMO "insert semicolons" is compiler's internal
    implementation, and should not appear in language specs.
    在 2013-6-12 下午5:06,"Jan Mercl" <0xj...@gmail.com <javascript:>>写道:
    On Wed, Jun 12, 2013 at 10:56 AM, David Symonds <dsym...@golang.org<javascript:>>
    wrote:
    If the error instead something like "missing {" on the line of the if
    statement, that would be much more helpful.
    I agree that this message is probably more helpful. But I don't think
    it's correct. The semicolon injection rules are defined at the
    scanner/token stream level. At the language grammar level, however, no
    "on the same line" concept really exists. (Or matter. Nor it should.)

    -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/groups/opt_out.
  • John Nagle at Jun 13, 2013 at 5:20 am

    On 6/12/2013 7:47 PM, Kevin Gillette wrote:
    The simplest way to describe lexical requirements is to put semicolon
    insertion rules in the spec
        The problem here isn't semicolon insertion. It's that the
    compiler produces the message

    syntax error: unexpected semicolon or newline before {

    where there is not "{" present. That's a bug.

    Try this in Go Playground:

    http://play.golang.org/p/LELWZ5795V

    "Format" produces the correct message

    prog.go:7:12: expected '{', found '++' (and 1 more errors)

    but "Run" produces

    prog.go:7: syntax error: unexpected semicolon or newline before {

    which is wrong.

         John Nagle

    --
    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/groups/opt_out.
  • Kevin Gillette at Jun 13, 2013 at 5:55 am
    It would be easy enough to correct, but requires reading an extra token
    ahead as soon as this current error is seen, just to make the determination
    that a '{' is missing.
    On Wednesday, June 12, 2013 11:20:39 PM UTC-6, John Nagle wrote:
    On 6/12/2013 7:47 PM, Kevin Gillette wrote:
    The simplest way to describe lexical requirements is to put semicolon
    insertion rules in the spec
    The problem here isn't semicolon insertion. It's that the
    compiler produces the message

    syntax error: unexpected semicolon or newline before {

    where there is not "{" present. That's a bug.

    Try this in Go Playground:

    http://play.golang.org/p/LELWZ5795V

    "Format" produces the correct message

    prog.go:7:12: expected '{', found '++' (and 1 more errors)

    but "Run" produces

    prog.go:7: syntax error: unexpected semicolon or newline before {

    which is wrong.

    John Nagle
    --
    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/groups/opt_out.
  • Kevin Gillette at Jun 13, 2013 at 5:55 am
    "easy enough in theory"
    On Wednesday, June 12, 2013 11:55:38 PM UTC-6, Kevin Gillette wrote:

    It would be easy enough to correct, but requires reading an extra token
    ahead as soon as this current error is seen, just to make the determination
    that a '{' is missing.
    On Wednesday, June 12, 2013 11:20:39 PM UTC-6, John Nagle wrote:
    On 6/12/2013 7:47 PM, Kevin Gillette wrote:
    The simplest way to describe lexical requirements is to put semicolon
    insertion rules in the spec
    The problem here isn't semicolon insertion. It's that the
    compiler produces the message

    syntax error: unexpected semicolon or newline before {

    where there is not "{" present. That's a bug.

    Try this in Go Playground:

    http://play.golang.org/p/LELWZ5795V

    "Format" produces the correct message

    prog.go:7:12: expected '{', found '++' (and 1 more errors)

    but "Run" produces

    prog.go:7: syntax error: unexpected semicolon or newline before {

    which is wrong.

    John Nagle
    --
    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/groups/opt_out.
  • Rémy Oudompheng at Jun 13, 2013 at 6:15 am
    Le 13 juin 2013 07:55, "Kevin Gillette" <extemporalgenome@gmail.com> a
    écrit :
    It would be easy enough to correct, but requires reading an extra token
    ahead as soon as this current error is seen, just to make the determination
    that a '{' is missing.
    >

    I don't understand this, how can you know there is an error unless you have
    read an extra token?
    It already happens, and the message needs simply say "instead of expected
    {" (for example) instead of "before {".

    Rémy.

    --
    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/groups/opt_out.
  • Ibrahim M. Ghazal at Jun 13, 2013 at 6:19 am

    On Thu, Jun 13, 2013 at 8:55 AM, Kevin Gillette wrote:
    It would be easy enough to correct, but requires reading an extra token
    ahead as soon as this current error is seen, just to make the
    determination
    that a '{' is missing.
    Other issues notwithstanding, how will the compiler distinguish between:

    if foo(); bar() {
      //...
    }

    and

    if foo()
    bar()

    and give an error that a semicolon is missing after foo()?

    --
    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/groups/opt_out.
  • Ibrahim M. Ghazal at Jun 13, 2013 at 6:20 am

    On Thu, Jun 13, 2013 at 9:18 AM, Ibrahim M. Ghazal wrote:

    and give an error that a semicolon is missing after foo()?
    curly brace, not semicolon.

    --
    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/groups/opt_out.
  • Rémy Oudompheng at Jun 13, 2013 at 6:35 am
    There is no distinction

    if foo()
    bar() {
    }

    is valid syntax.

    2013/6/13, Ibrahim M. Ghazal <imgx64@gmail.com>:
    On Thu, Jun 13, 2013 at 8:55 AM, Kevin Gillette
    wrote:
    It would be easy enough to correct, but requires reading an extra token
    ahead as soon as this current error is seen, just to make the
    determination
    that a '{' is missing.
    Other issues notwithstanding, how will the compiler distinguish between:

    if foo(); bar() {
    //...
    }

    and

    if foo()
    bar()

    and give an error that a semicolon is missing after foo()?

    --
    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/groups/opt_out.

    --
    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/groups/opt_out.
  • Ibrahim M. Ghazal at Jun 13, 2013 at 6:46 am

    On Thu, Jun 13, 2013 at 9:34 AM, Rémy Oudompheng wrote:

    There is no distinction

    if foo()
    bar() {
    }

    is valid syntax.
    Yes, that's exactly my point. It's impossible to give an error that a
    { is missing after foo() because having a semicolon there is valid
    syntax.

    --
    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/groups/opt_out.
  • Nico at Jun 13, 2013 at 9:11 am
    Is it possible to distinguish a real semicolon from an inserted one?

    If so, the error message could be made more informative by pointing out
    the error is caused by an inserted semicolon.

    --
    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/groups/opt_out.
  • Jan Mercl at Jun 13, 2013 at 9:28 am

    On Thu, Jun 13, 2013 at 11:11 AM, Nico wrote:
    Is it possible to distinguish a real semicolon from an inserted one?
    In theory it is possible, I think:

             semi:
                    ';'
    LINJECTED_SEMI
             ;

    Then the rsc's extended errors [1] technique might be perhaps able to
    profit from it.

       [1]: http://research.swtch.com/yyerror

    -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/groups/opt_out.
  • Daniel Morsing at Jun 15, 2013 at 7:59 am

    On Thu, Jun 13, 2013 at 11:28 AM, Jan Mercl wrote:
    On Thu, Jun 13, 2013 at 11:11 AM, Nico wrote:
    Is it possible to distinguish a real semicolon from an inserted one?
    In theory it is possible, I think:

    semi:
    ';'
    LINJECTED_SEMI
    ;

    Then the rsc's extended errors [1] technique might be perhaps able to
    profit from it.

    [1]: http://research.swtch.com/yyerror

    -j
    This wont work since the error technique can only look at the stack
    after reduction. Both variants of a semicolon will just be reduced to
    semi on the stack.

    There are other techniques you can use for error handling, like
    inserting rules for incorrect grammar which only job is it emit a
    pretty error. I am not a fan of doing so, because it makes it hard to
    figure out what is grammar and what is error handling.
    --
    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/groups/opt_out.
    --
    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/groups/opt_out.
  • Sam Harwell at Jun 15, 2013 at 3:12 pm
    One of the things I like about having numbered errors is it provides a place for users to add additional documentation when a particular error is occurring in situations that may not be intuitive to all users. In this case, a simple example could be added so users searching for the error code would immediately see which part of their code is resulting in the error, along with information to guide them to a solution.

    --
    Sam Harwell
    Owner, Lead Developer
    http://tunnelvisionlabs.com

    -----Original Message-----
    From: golang-nuts@googlegroups.com On Behalf Of Daniel Morsing
    Sent: Saturday, June 15, 2013 2:59 AM
    To: Jan Mercl
    Cc: Nico; golang-nuts
    Subject: Re: [go-nuts] Re: "syntax error: unexpected semicolon or newline before {"
    On Thu, Jun 13, 2013 at 11:28 AM, Jan Mercl wrote:
    On Thu, Jun 13, 2013 at 11:11 AM, Nico wrote:
    Is it possible to distinguish a real semicolon from an inserted one?
    In theory it is possible, I think:

    semi:
    ';'
    LINJECTED_SEMI
    ;

    Then the rsc's extended errors [1] technique might be perhaps able to
    profit from it.

    [1]: http://research.swtch.com/yyerror

    -j
    This wont work since the error technique can only look at the stack
    after reduction. Both variants of a semicolon will just be reduced to
    semi on the stack.

    There are other techniques you can use for error handling, like
    inserting rules for incorrect grammar which only job is it emit a
    pretty error. I am not a fan of doing so, because it makes it hard to
    figure out what is grammar and what is error handling.
    --
    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/groups/opt_out.
    --
    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/groups/opt_out.


    --
    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/groups/opt_out.
  • John Nagle at Jun 15, 2013 at 6:39 pm

    On 6/15/2013 8:12 AM, Sam Harwell wrote:
    One of the things I like about having numbered errors...
        Go's syntax isn't complex enough that it needs numbered errors.
    It's LALR(1), and context-independent. You don't have problems
    like C++, where the parser needs to know which identifiers are
    types, and that information is dependent on include files.

        (On the other hand, the SQL packages really need to be
    returning SQL error codes, so that programs can tell what
    happened. Returning English language text is not sufficient.)

        Something that seems to have gone out of favor in compiler error
    messages is showing the character at which the error was
    detected. I used to do that when I wrote parsers, but
    it's rare today. It's a useful discipline for the
    developers to have to point out exactly where the problem is.
    (It also makes you realize how badly YACC sucks.)

        John Nagle

    --
    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/groups/opt_out.
  • Matthew Kane at Jun 15, 2013 at 6:57 pm
    Yes, but a semicolon without a condition expression would not be valid.
    On Jun 13, 2013 2:46 AM, "Ibrahim M. Ghazal" wrote:

    On Thu, Jun 13, 2013 at 9:34 AM, Rémy Oudompheng
    wrote:
    There is no distinction

    if foo()
    bar() {
    }

    is valid syntax.
    Yes, that's exactly my point. It's impossible to give an error that a
    { is missing after foo() because having a semicolon there is valid
    syntax.

    --
    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/groups/opt_out.

    --
    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/groups/opt_out.
  • Jan Mercl at Jun 13, 2013 at 6:10 am

    On Thu, Jun 13, 2013 at 7:20 AM, John Nagle wrote:
    On 6/12/2013 7:47 PM, Kevin Gillette wrote:
    The simplest way to describe lexical requirements is to put semicolon
    insertion rules in the spec
    The problem here isn't semicolon insertion. It's that the
    compiler produces the message

    syntax error: unexpected semicolon or newline before {

    where there is not "{" present. That's a bug.
    No it is not abug. Before seeing the expected and required '{', the
    (unexpected and not permitted by the language grammar) semicolon was
    seen by the compiler. Nothing in the message implies the '{' token is
    present.

    The "before" is the one as in "happened before".

    -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/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJun 12, '13 at 7:33a
activeJun 15, '13 at 6:57p
posts25
users14
websitegolang.org

People

Translate

site design / logo © 2017 Grokbase