

Go's Declaration Syntax - pufuwozu
http://blog.golang.org/2010/07/gos-declaration-syntax.html

======
igravious
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
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.

~~~
enneff
It is used correctly in the article. The meaning of the word 'prove' in that
saying is anologous to 'test' or 'try'. As in 'proving grounds'.

~~~
igravious
Interesting. I never looked up the etymology of that expression. Thanks.

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

~~~
by
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.

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

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

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

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

~~~
kaib
> "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
What are you doing in Go on a daily basis?

~~~
kaib
At work I'm writing internal infrastructure, at home I'm working on a CNC
controller.

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

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

