code review 193101: channel types parsed not according to spec by 6g

channel types parsed not according to spec by 6g

[gri, 2010-01-26 05:15:47]

Hello r, rsc (cc: golang-dev@googlegroups.com),

I'd like you to review this change.

[r2, 2010-01-26 05:33:18]

one of the lines must be correct, the other incorrect. the incorrect one should
be marked with an error tag.

[rsc, 2010-01-26 05:40:23]

should use errchk.

> channel types parsed not according to spec by 6g

good test, but where does the spec say how to parse

    chan <- chan int

?

[gri, 2010-01-26 05:47:41]

Elsewhere in the spec we rely on the syntax to express precedence. Also, it
seems rather odd that

   chan <- chan int

should be parsed as

   chan (<-chan int)

while

   chan <- int

is parsed as

   chan<- (int)

given the same syntax. It is clearly the intention of the syntax. Perhaps
there should be an example to make it 100% clear.
- Robert


On Mon, Jan 25, 2010 at 9:40 PM, Russ Cox <rsc@golang.org> wrote:

> should use errchk.
>
> > channel types parsed not according to spec by 6g
>
> good test, but where does the spec say how to parse
>
>    chan <- chan int
>
> ?
>

[gri, 2010-01-26 05:52:38]

Hello r, rsc (cc: golang-dev@googlegroups.com),

Please take another look.

[r2, 2010-01-26 05:56:24]

LGTM

[gri, 2010-01-26 06:10:40]

*** Submitted as http://code.google.com/p/go/source/detail?r=a1eb0cc5770d ***

channel types parsed not according to spec by 6g

R=r, rsc
CC=golang-dev
http://codereview.appspot.com/193101

[rsc, 2010-01-26 06:16:45]

In the spec I see that chan ElementType is a valid channel type
(the first one listed, in fact), so it is valid to parse chan <- chan int
as chan ElementType where the ElementType is <- chan int.

I don't know what the intent of the syntax is; I do know
what the syntax says literally, and I don't see how to use
it to resolve this question.  I'm not arguing against your
proposed rule, and I'll fix 6g, but I would like to see the spec
state the parsing precedence explicitly.  The usual precedence
rules do not apply, because <- can be parsed either as a left-unary
or as a right-unary operator, and that doesn't happen elsewhere in
the language.

I think it would suffice to add a note near the channel syntax
that in the chan ElementType case, the ElementType cannot
itself be a RecvChannel.

The flip side of the example you gave is that it's also rather odd that
    chan int
is parsed as
    chan (int)
but
    chan <-chan int
is parsed as
    chan<- (chan int)
given the same syntax.

It's an odd case either way.

Russ

[gri, 2010-01-26 06:25:14]

On Mon, Jan 25, 2010 at 10:16 PM, Russ Cox <rsc@golang.org> wrote:

> In the spec I see that chan ElementType is a valid channel type
> (the first one listed, in fact), so it is valid to parse chan <- chan int
> as chan ElementType where the ElementType is <- chan int.
>

you have a point


>
> I don't know what the intent of the syntax is; I do know
> what the syntax says literally, and I don't see how to use
> it to resolve this question.  I'm not arguing against your
> proposed rule, and I'll fix 6g, but I would like to see the spec
> state the parsing precedence explicitly.  The usual precedence
> rules do not apply, because <- can be parsed either as a left-unary
> or as a right-unary operator, and that doesn't happen elsewhere in
> the language.


> I think it would suffice to add a note near the channel syntax
> that in the chan ElementType case, the ElementType cannot
> itself be a RecvChannel.
>

yes; one probably should add a couple of examples making the intent very
clear


> The flip side of the example you gave is that it's also rather odd that
>     chan int
> is parsed as
>    chan (int)
> but
>    chan <-chan int
> is parsed as
>    chan<- (chan int)
> given the same syntax.
>
> It's an odd case either way.
>
> Russ
>