9 ms·

Go's Declaration Syntax

68 points by pufuwozu 16y ago

mkramlich 16y ago
great explanation and advocacy, and also good to see Pike's name as the author, gives the language a cred boost in my eyes. maybe i'll add it to the same bucket I consider D to be in as a possible successor to C for certain niches.
enneff 16y ago
Includes a discussion of C's declaration syntax. Some stuff in there I didn't know.
Groxx 16y ago
Could use a better title... it's the golang.org's blog, and it's an explanation of the syntax, which is not really implied by "Go's declaration syntax". With just the domain and title, I'd assumed this was just documentation (as sometimes gets posted on hn), not discussion, and skipped over it several times. All in all interesting, and I definitely agree with the improvement with their "function-returning function which accepts a function as an argument" example. An interesting departure from C & languages influenced by C (ie: most).
- derefr 16y ago
  Indeed. C-style declarations have always been intuitionally-opaque to me (I've always had to concentrate on them to get what they're saying), but the Go example: f func(func(int,int) int, int) func(int, int) int is a simple mechanical transformation away from being a Haskell declaration: f :: ((Int, Int) -> Int, Int) -> (Int, Int) -> Int
- kaib 16y ago
  > "function-returning function which accepts a function as an argument" I write almost exclusively Go day to day and I've noticed I no longer shy away from function pointers like in C. It's not that the C version can't be mastered, it's just that I'd rather not occupy a significant chunk of my brain with it. Another interesting observation is that I can now pretty easily switch between C and Go if I need to, the declaration syntax seems different enough that my brain can do the leap. Sadly less true for semicolons (Go omits most, C doesn't)
  - jgrahamc 16y ago
    What are you doing in Go on a daily basis?
    - kaib 16y ago
      At work I'm writing internal infrastructure, at home I'm working on a CNC controller.
- Groxx 16y ago
  -1? seriously? What's objectionable about this?
heatdeath 16y ago
We took what you're used to... and flipped it around! Did I just blow your mind??
unwind 16y ago
As a crazy random thought, wouldn't '@' work well as an alternative to the asterisk to dereference pointers? It's available, it's ASCII, it's pronounced "at" which seems to jive with pointer semantics, and it's not used in C-like languages. Just a very quick thought after reading Mr Pike's closing words that the use of the asterisk for pointers makes the syntax a bit clumsier than they would have wished.
- by 16y ago
  That would invert the use in Pascal where P := @X; means assign the address of X to P. And Y := P^; means dereference P and assign the result to Y. I think anyone who has written any Pascal/Delphi would prefer ^ for dereference.
  - btilly 16y ago
    Anyone who has done a lot of bit twiddling in C has other uses for ^. (I find it ironic that 4^5 has an obvious meaning outside of programming that it doesn't have in a large variety of widely used programming languages.)
    - Groxx 16y ago
      C and many other languages. ^ is very nearly a universal code-XOR, at least where single-characters are concerned.
    - by 16y ago
      I suppose they should be allocated based on frequency of use within the intended domain of the language, with the most frequent getting first choice. I guess pointer dereferencing would be more important than xor for most domains. Not that I am particularly advocating ^ for pointers, * is just as good, but I do think using @ for the opposite of its meaning in Pascal would be confusing.
- nddrylliog 16y ago
  That's very funny sir, because http://ooc-lang.org/ http://ooc-lang.org/ happens to do just that. In addition, & and @ are postfix, which pretty much settles the question.
jeberle 16y ago
You might compare the results with SPECS: http://en.wikipedia.org/wiki/Significantly_Prettier_and_Easier_C%2B%2B_Syntax http://en.wikipedia.org/wiki/Significantly_Prettier_and_Easi... -- an alternate syntax for C++. I find its productions clearer than those of Go's.
sambeau 16y ago
The more I use Go the more I realise how much thought has gone into every language decision and (just as importantly) how much restraint has gone into the design. It's my first tool of choice for everything now.
igravious 16y ago
The declaration syntax contradicts the commentary. Functions do not read from left to right. The example of func main(argc int, argv *[]byte) int is explained as "function main takes an int and a pointer to a slice of bytes and returns an int" but it should read "main is a function which takes an int and a pointer to a slice of bytes and returns an int" just like x int means "x is an integer". Reading left to right the variable name should come first for functions as for other variables so the function syntax should be main func(argc int, argv *[]byte) int But this can't be so because this appears to be the syntax that function variables use f func(func(int,int) int, int) int which is explained as "Here's a declaration of a function variable (analogous to a function pointer in C)". Also the article says "Pointers are the exception that proves the rule" because "For familiarity, Go's pointers use the * notation from C, but we could not bring ourselves to make a similar reversal for pointer types.". Putting these two observations together I would say that Go's declaration syntax fails in its stated mission of simplicity and regularity. EDIT: can't seem to work out how to code markup on HN, anyway I hope I've made what I'm trying to say clear enough. UPDATE: two spaces at the start of a line seems to work
- shasta 16y ago
  I hope this is the last time I see "the exception that proves the rule" in the context of programming languages. It's a wart. You know what would better prove the rule? No exceptional cases at all.
  - igravious 16y ago
    Yes! Absolutely. The phrase "the exception proves the rule" is a tired, worn out, clichéd contradiction in terms that must have meant something at one time I'm sure but can only be superfluous in most cases now.
    - shasta 16y ago
      I think I've heard it used reasonably, but I can't really remember the specifics. Basically, it's when the cause for the exception follows naturally from the logic behind the rule. Contrived example: If something holds for most birds, an exception for penguins might qualify. In any case, this is just an exception that breaks the rule.

68 points by pufuwozu 16y ago

great explanation and advocacy, and also good to see Pike's name as the author, gives the language a cred boost in my eyes. maybe i'll add it to the same bucket I consider D to be in as a possible successor to C for certain niches.

enneff 16y ago

Includes a discussion of C's declaration syntax. Some stuff in there I didn't know.

Groxx 16y ago

Could use a better title... it's the golang.org's blog, and it's an explanation of the syntax, which is not really implied by "Go's declaration syntax". With just the domain and title, I'd assumed this was just documentation (as sometimes gets posted on hn), not discussion, and skipped over it several times. All in all interesting, and I definitely agree with the improvement with their "function-returning function which accepts a function as an argument" example. An interesting departure from C & languages influenced by C (ie: most).

derefr 16y ago
Indeed. C-style declarations have always been intuitionally-opaque to me (I've always had to concentrate on them to get what they're saying), but the Go example: f func(func(int,int) int, int) func(int, int) int is a simple mechanical transformation away from being a Haskell declaration: f :: ((Int, Int) -> Int, Int) -> (Int, Int) -> Int
kaib 16y ago
> "function-returning function which accepts a function as an argument" I write almost exclusively Go day to day and I've noticed I no longer shy away from function pointers like in C. It's not that the C version can't be mastered, it's just that I'd rather not occupy a significant chunk of my brain with it. Another interesting observation is that I can now pretty easily switch between C and Go if I need to, the declaration syntax seems different enough that my brain can do the leap. Sadly less true for semicolons (Go omits most, C doesn't)
- jgrahamc 16y ago
  What are you doing in Go on a daily basis?
  - kaib 16y ago
    At work I'm writing internal infrastructure, at home I'm working on a CNC controller.
Groxx 16y ago
-1? seriously? What's objectionable about this?

heatdeath 16y ago

We took what you're used to... and flipped it around! Did I just blow your mind??

unwind 16y ago

As a crazy random thought, wouldn't '@' work well as an alternative to the asterisk to dereference pointers? It's available, it's ASCII, it's pronounced "at" which seems to jive with pointer semantics, and it's not used in C-like languages. Just a very quick thought after reading Mr Pike's closing words that the use of the asterisk for pointers makes the syntax a bit clumsier than they would have wished.

by 16y ago
That would invert the use in Pascal where P := @X; means assign the address of X to P. And Y := P^; means dereference P and assign the result to Y. I think anyone who has written any Pascal/Delphi would prefer ^ for dereference.
- btilly 16y ago
  Anyone who has done a lot of bit twiddling in C has other uses for ^. (I find it ironic that 4^5 has an obvious meaning outside of programming that it doesn't have in a large variety of widely used programming languages.)
  - Groxx 16y ago
    C and many other languages. ^ is very nearly a universal code-XOR, at least where single-characters are concerned.
  - by 16y ago
    I suppose they should be allocated based on frequency of use within the intended domain of the language, with the most frequent getting first choice. I guess pointer dereferencing would be more important than xor for most domains. Not that I am particularly advocating ^ for pointers, * is just as good, but I do think using @ for the opposite of its meaning in Pascal would be confusing.
nddrylliog 16y ago
That's very funny sir, because http://ooc-lang.org/ http://ooc-lang.org/ happens to do just that. In addition, & and @ are postfix, which pretty much settles the question.

jeberle 16y ago

You might compare the results with SPECS: http://en.wikipedia.org/wiki/Significantly_Prettier_and_Easier_C%2B%2B_Syntax http://en.wikipedia.org/wiki/Significantly_Prettier_and_Easi... -- an alternate syntax for C++. I find its productions clearer than those of Go's.

sambeau 16y ago

The more I use Go the more I realise how much thought has gone into every language decision and (just as importantly) how much restraint has gone into the design. It's my first tool of choice for everything now.

igravious 16y ago

The declaration syntax contradicts the commentary. Functions do not read from left to right. The example of func main(argc int, argv *[]byte) int is explained as "function main takes an int and a pointer to a slice of bytes and returns an int" but it should read "main is a function which takes an int and a pointer to a slice of bytes and returns an int" just like x int means "x is an integer". Reading left to right the variable name should come first for functions as for other variables so the function syntax should be main func(argc int, argv *[]byte) int But this can't be so because this appears to be the syntax that function variables use f func(func(int,int) int, int) int which is explained as "Here's a declaration of a function variable (analogous to a function pointer in C)". Also the article says "Pointers are the exception that proves the rule" because "For familiarity, Go's pointers use the * notation from C, but we could not bring ourselves to make a similar reversal for pointer types.". Putting these two observations together I would say that Go's declaration syntax fails in its stated mission of simplicity and regularity. EDIT: can't seem to work out how to code markup on HN, anyway I hope I've made what I'm trying to say clear enough. UPDATE: two spaces at the start of a line seems to work

shasta 16y ago
I hope this is the last time I see "the exception that proves the rule" in the context of programming languages. It's a wart. You know what would better prove the rule? No exceptional cases at all.
- igravious 16y ago
  Yes! Absolutely. The phrase "the exception proves the rule" is a tired, worn out, clichéd contradiction in terms that must have meant something at one time I'm sure but can only be superfluous in most cases now.
  - shasta 16y ago
    I think I've heard it used reasonably, but I can't really remember the specifics. Basically, it's when the cause for the exception follows naturally from the logic behind the rule. Contrived example: If something holds for most birds, an exception for penguins might qualify. In any case, this is just an exception that breaks the rule.