7 ms·

See the excellent discussion of Go's declaration syntax [1] and compare with "The Spiral Rule" for C [2]. [1] http://golang.org/doc/articles/gos_declaration_sy

by asolove 14y ago

See the excellent discussion of Go's declaration syntax [1] and compare with "The Spiral Rule" for C [2]. [1] http://golang.org/doc/articles/gos_declaration_syntax.html http://golang.org/doc/articles/gos_declaration_syntax.html [2] http://c-faq.com/decl/spiral.anderson.html http://c-faq.com/decl/spiral.anderson.html

mseepgood 14y ago
[1] finally explains to me why so many new languages like Scala and Kotlin and Go use the right-hand side declaration syntax. And it also automatically aligns multiple variable identifiers in one column.
- pcwalton 14y ago
  In Rust the choice was much simpler: we didn't want to use the lexer hack, and we wanted to avoid arbitrary lookahead in the parser. Consider: let hashmap<int,str> x; let x; After parsing the "let" we don't know whether to parse a type (which can be arbitrarily long) or a variable name. Switching to postfix types neatly solves the problem: let x: hashmap<int,str>; let x;
  - lobster_johnson 14y ago
    I like how Rust uses colons for the type, compared to Go's colonless syntax. The colon works as a nice visual delimiter. I like a lot about Rust, but one thing I vehemently dislike is how type names are all lowercase by convention. It's unambiguous in variable declarations, but everywhere else it reduces visual information. In most other languages, I immediately know that "Foo" is a type and that "foo" is a variable. Even though Rust allows for omitting the type in many places, it quickly becomes a sea of lowercase for me. This, plus the focus on short keywords/identifiers and C++-style syntax (::, semicolons), makes Rust look a lot gnarlier than Go, overall. It also seems to me that Rust still hasn't fully adopted its "object syntax"? One aspect of Go I really like is how functions can be used as methods and you design entire interfaces associated with a type -- the best of object-orientation without the worst. Rust also does this, but on the whole it seems the current standard library is not designed around this philosophy. For example, code uses `vec::len(foo)` instead of `foo.len()`. Are you moving away from the OO syntax, or is it simply considered a stylistic choice?
    - pcwalton 14y ago
      You'll be happy to know that these issues are being addressed: * I agree about type capitalization. I try to capitalize my types in new Rust code, and I'm advocating switching to it generally. It is currently on the roadmap. (It's not just a stylistic thing; we can fix several issues in the grammar that way, most notably the distinction between an enum like None and a variable like x.) * The keywords are going to stay short (although some of them are being revised to read better; e.g. "cont" -> "again", "iface" -> "trait"), but identifiers are going to lengthen in new code. * '::' may change to '.', to make it easier on the eyes. I personally prefer '.', and am advocating the change. * You're right that Rust hasn't fully adopted dot-notation. This is an artifact of dot-notation being introduced later in the design, and we're in the process of transitioning code from vec::len(x) to x.len(). We definitely aren't moving away from the OO syntax; in fact we're moving toward traits [1] and maximally-minimal classes as a way to unify OO, Go-like interfaces, and Haskell-like typeclasses under one simple, coherent system. I'd prefer it if semicolons stayed, however; I think automatic semicolon insertion is more trouble than it's worth, as it ruins people's house bracing styles and causes confusing errors. That said, the way a trailing semicolon changes a block's return value is very confusing, and I'm pretty sure we can fix that issue. [1]: https://github.com/mozilla/rust/wiki/Proposal-for-unifying-traits-and-interfaces https://github.com/mozilla/rust/wiki/Proposal-for-unifying-t...
      - kibwen 14y ago
        "identifiers are going to lengthen in new code" I'll be holding you to this promise. :) Indeed, what's the point of super-short keywords if not to allow identifiers to be more descriptive while maintaining an 80-column limit?
      - lobster_johnson 14y ago
        Wow. I'm pleasantly surprised that all of my issues are actually being addressed -- I was thinking that I might be in the minority on these points. I need to be paying closer attention to the mailing list. While I love that you are making major changes, I am sure that you are aware that the instability of the language is a problem for many people. I have been watching from the sidelines for a good while now, but aside from testing new builds and reading the developer blogs, I dare not start using Rust for anything. Niko Matsakis's recent blog entry about mutability was particularly disappointing as it seems such a basic idea should have been settled much earlier. I can appreciate the kind of experimental, agile approach to language design, of course; but while Rust is germinating, I have been forced to fall back to Go. I really hope the dust settles soon so the language can stabilize and mature. As for the semicolons, I think a strict, well-defined rule such as the one used by Go is sufficient. Actually, Go is a bit too rigid about semicolon insertion for my taste. The following, for example, will not compile, despite the fact that the ending brace is expected by the parser: house := &House{ color: Green, floors: 3, patio: true } On the other hand, Go is perfectly happy about: import ( "fmt" "io" ) ...but I have not looked into why this is a special case.
lenkite 14y ago
I agree with their reasons. But Go should have been consistent and made the reversal even for pointer types and chosen another operator say postfix (^) for pointer instead of (*) to avoid conflating with multiplication. So effectively "those ties mean that we cannot break completely from using parentheses to disambiguate types and expressions in the grammar". Looks like Go's authors recognized all the issues very well and still went ahead with the final, wrong decision IMHO. They might as well have not bothered with postfix.

by asolove 14y ago

mseepgood 14y ago

[1] finally explains to me why so many new languages like Scala and Kotlin and Go use the right-hand side declaration syntax. And it also automatically aligns multiple variable identifiers in one column.

pcwalton 14y ago
In Rust the choice was much simpler: we didn't want to use the lexer hack, and we wanted to avoid arbitrary lookahead in the parser. Consider: let hashmap<int,str> x; let x; After parsing the "let" we don't know whether to parse a type (which can be arbitrarily long) or a variable name. Switching to postfix types neatly solves the problem: let x: hashmap<int,str>; let x;
- lobster_johnson 14y ago
  I like how Rust uses colons for the type, compared to Go's colonless syntax. The colon works as a nice visual delimiter. I like a lot about Rust, but one thing I vehemently dislike is how type names are all lowercase by convention. It's unambiguous in variable declarations, but everywhere else it reduces visual information. In most other languages, I immediately know that "Foo" is a type and that "foo" is a variable. Even though Rust allows for omitting the type in many places, it quickly becomes a sea of lowercase for me. This, plus the focus on short keywords/identifiers and C++-style syntax (::, semicolons), makes Rust look a lot gnarlier than Go, overall. It also seems to me that Rust still hasn't fully adopted its "object syntax"? One aspect of Go I really like is how functions can be used as methods and you design entire interfaces associated with a type -- the best of object-orientation without the worst. Rust also does this, but on the whole it seems the current standard library is not designed around this philosophy. For example, code uses `vec::len(foo)` instead of `foo.len()`. Are you moving away from the OO syntax, or is it simply considered a stylistic choice?
  - pcwalton 14y ago
    You'll be happy to know that these issues are being addressed: * I agree about type capitalization. I try to capitalize my types in new Rust code, and I'm advocating switching to it generally. It is currently on the roadmap. (It's not just a stylistic thing; we can fix several issues in the grammar that way, most notably the distinction between an enum like None and a variable like x.) * The keywords are going to stay short (although some of them are being revised to read better; e.g. "cont" -> "again", "iface" -> "trait"), but identifiers are going to lengthen in new code. * '::' may change to '.', to make it easier on the eyes. I personally prefer '.', and am advocating the change. * You're right that Rust hasn't fully adopted dot-notation. This is an artifact of dot-notation being introduced later in the design, and we're in the process of transitioning code from vec::len(x) to x.len(). We definitely aren't moving away from the OO syntax; in fact we're moving toward traits [1] and maximally-minimal classes as a way to unify OO, Go-like interfaces, and Haskell-like typeclasses under one simple, coherent system. I'd prefer it if semicolons stayed, however; I think automatic semicolon insertion is more trouble than it's worth, as it ruins people's house bracing styles and causes confusing errors. That said, the way a trailing semicolon changes a block's return value is very confusing, and I'm pretty sure we can fix that issue. [1]: https://github.com/mozilla/rust/wiki/Proposal-for-unifying-traits-and-interfaces https://github.com/mozilla/rust/wiki/Proposal-for-unifying-t...
    - kibwen 14y ago
      "identifiers are going to lengthen in new code" I'll be holding you to this promise. :) Indeed, what's the point of super-short keywords if not to allow identifiers to be more descriptive while maintaining an 80-column limit?
    - lobster_johnson 14y ago
      Wow. I'm pleasantly surprised that all of my issues are actually being addressed -- I was thinking that I might be in the minority on these points. I need to be paying closer attention to the mailing list. While I love that you are making major changes, I am sure that you are aware that the instability of the language is a problem for many people. I have been watching from the sidelines for a good while now, but aside from testing new builds and reading the developer blogs, I dare not start using Rust for anything. Niko Matsakis's recent blog entry about mutability was particularly disappointing as it seems such a basic idea should have been settled much earlier. I can appreciate the kind of experimental, agile approach to language design, of course; but while Rust is germinating, I have been forced to fall back to Go. I really hope the dust settles soon so the language can stabilize and mature. As for the semicolons, I think a strict, well-defined rule such as the one used by Go is sufficient. Actually, Go is a bit too rigid about semicolon insertion for my taste. The following, for example, will not compile, despite the fact that the ending brace is expected by the parser: house := &House{ color: Green, floors: 3, patio: true } On the other hand, Go is perfectly happy about: import ( "fmt" "io" ) ...but I have not looked into why this is a special case.

lenkite 14y ago

I agree with their reasons. But Go should have been consistent and made the reversal even for pointer types and chosen another operator say postfix (^) for pointer instead of (*) to avoid conflating with multiplication. So effectively "those ties mean that we cannot break completely from using parentheses to disambiguate types and expressions in the grammar". Looks like Go's authors recognized all the issues very well and still went ahead with the final, wrong decision IMHO. They might as well have not bothered with postfix.