[go-nuts] Parsing Go code without context

On 22/02/2014, at 6:50 PM, "⚛" wrote:

The slide states that "Go programs can be parsed without context (unlike C and C++)". I am not sure what this sentence means. Can somebody explain?

On Sat, Feb 22, 2014 at 9:31 AM, Dan Kortschak wrote:
type knowledge may be required to disambiguate parsing of C and C++

On 22/02/2014, at 7:55 PM, "Jan Mercl" wrote:

In a certain sense this is true for Go as well.

f(x)

can be a call operation or conversion operation, depending on the
knowledge of what f stands for.

On Saturday, February 22, 2014 11:05:19 AM UTC+1, Aram Hăvărneanu wrote:
You've written a Go compiler,

The extreme example is
C++.

--
Aram Hăvărneanu

On Saturday, 22 February 2014 09:24:54 UTC, Jan Mercl wrote:

In a certain sense this is true for Go as well.

f(x)

can be a call operation or conversion operation, depending on the
knowledge of what f stands for.

On Saturday, 22 February 2014 15:45:57 UTC, Benjamin Measures wrote:
Context-free grammers keep things really simple.

On Sat, Feb 22, 2014 at 4:45 PM, Benjamin Measures wrote:

Go has function types. So, for the above example, f is just a type (no
knowledge needed).

On Sat, Feb 22, 2014 at 12:28 PM, Jan Mercl wrote:

Fun fact. Go syntax is actually not a CFG. It's actually an ambiguous
grammar for which you cannot even write a yacc parser. I know the gc
uses a yacc based parser - yet the previous claim still holds ;-)

On Sat, Feb 22, 2014 at 9:38 PM, Russ Cox wrote:

Whether this is true depends on what you define the syntax to be. Someone
brought up conversions and function calls, but in Go those *are* the same
syntax, so there is no ambiguity at the syntactic level. (The spec
distinguishes them, but that doesn't mean a parser must.) In contrast, the
"X * Y" example given earlier for C really does have two irreconcilably
different parses, and without type information you cannot tell which it is.
Yep, I agree and I explicitly agreed to all of the above earlier.
If you think Go's grammar is ambiguous, I think you are making too many
distinctions in the parser.

On Saturday, February 22, 2014 2:17:44 PM UTC-7, Jan Mercl wrote:

On Sat, Feb 22, 2014 at 9:38 PM, Russ Cox <r...@golang.org <javascript:>>
wrote:
is.

Yep, I agree and I explicitly agreed to all of the above earlier.
Actually it's not about me thinking this or that; the fact that the
grammar is ambiguous is right in the specs[0]:

""""
A parsing ambiguity arises when a composite literal using the TypeName
form of the LiteralType appears between the keyword and the opening
brace of the block of an "if", "for", or "switch" statement, because
the braces surrounding the expressions in the literal are confused
with those introducing the block of statements. To resolve the
ambiguity in this rare case, the composite literal must appear within
parentheses.
""""

In fact, the yacc based parser of gc parses a different language (the
not ambiguous one). This language is only slightly different and is
produced by small tokenizer hacks (lbrace vs '{', fixlbrace(),
contextual '()' and '[]' pairs tracing/balancing deciding when to hand
which token for the same { symbol to the parser, ...).

This is in no way saying that anything is wrong with this! It's just
that the Go grammar really _is_ ambiguous. In just one place and in a
such a place where the "problem" can be solved easily. And in a way
which, IMHO, benefits the programmer, who is _not_ limited in the same
way formal grammar of most parser generators is.

As stated before - it's a fun fact, not a complain. I actually
appreciate this design detail. It trades better readability in the
common case for only a little bit more complicated parser.

[0]: http://golang.org/ref/spec#Composite_literals

-j

On Saturday, February 22, 2014 9:38:45 PM UTC+1, Russ Cox wrote:
On Sat, Feb 22, 2014 at 12:28 PM, Jan Mercl <0xj...@gmail.com<javascript:>
Whether this is true depends on what you define the syntax to be. Someone
brought up conversions and function calls, but in Go those *are* the same
syntax, so there is no ambiguity at the syntactic level. (The spec
distinguishes them, but that doesn't mean a parser must.) In contrast, the
"X * Y" example given earlier for C really does have two irreconcilably
different parses, and without type information you cannot tell which it is.

distinctions in the parser.

Russ

On 22 February 2014 08:20, ⚛ wrote:

Hello. I was reading slides of a talk given by Russ and have problem
understanding the following slide:

http://talks.golang.org/2014/research.slide#30

The slide states that "Go programs can be parsed without context (unlike C
and C++)". I am not sure what this sentence means. Can somebody explain?