"syntax error: unexpected semicolon or newline before {"

[Liigo Zhuang]

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/

[Jesse McNelis]

On Wed, Jun 12, 2013 at 5:33 PM, Liigo Zhuang <com....@gmail.com> 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

[David Symonds]

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.

[Jan Mercl]

On Wed, Jun 12, 2013 at 10:27 AM, David Symonds <dsym...@golang.org> 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

[David Symonds]

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.

[Robert Melton]

On Wed, Jun 12, 2013 at 4:56 AM, David Symonds <dsym...@golang.org> 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. 

[Jan Mercl]

On Wed, Jun 12, 2013 at 10:56 AM, David Symonds <dsym...@golang.org> 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

[Liigo Zhuang]

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.

[Ian Lance Taylor]

On Wed, Jun 12, 2013 at 4:34 PM, Liigo Zhuang <com....@gmail.com> 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

[Kevin Gillette]

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

[John Nagle]

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

[Kevin Gillette]

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.

[Kevin Gillette]

"easy enough in theory"

[Jan Mercl]

On Thu, Jun 13, 2013 at 7:20 AM, John Nagle <na...@animats.com> 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

[Rémy Oudompheng]

Le 13 juin 2013 07:55, "Kevin Gillette" <extempor...@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.

[Ibrahim M. Ghazal]

On Thu, Jun 13, 2013 at 8:55 AM, Kevin Gillette <extempor...@gmail.com> 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()?

[Ibrahim M. Ghazal]

On Thu, Jun 13, 2013 at 9:18 AM, Ibrahim M. Ghazal <img...@gmail.com> wrote:

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

curly brace, not semicolon.

[Rémy Oudompheng]

There is no distinction

if foo()
bar() {
}

is valid syntax.

2013/6/13, Ibrahim M. Ghazal <img...@gmail.com>:

> --
> 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...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

[Ibrahim M. Ghazal]

On Thu, Jun 13, 2013 at 9:34 AM, Rémy Oudompheng
<remyoud...@gmail.com> 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.

[Nico]

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.

[Jan Mercl]

On Thu, Jun 13, 2013 at 11:11 AM, Nico <nicolas...@gmail.com> 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

[Daniel Morsing]

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.

[Sam Harwell]

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

[John Nagle]

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

[Matthew Kane]

Yes, but a semicolon without a condition expression would not be valid.