GCC to merge Go support

[Posted January 27, 2010 by corbet]

From:		David Edelsohn <edelsohn-AT-gnu.org>
To:		<iant-AT-google.com>,<gcc-AT-gcc.gnu.org>
Subject:		gccgo language contribution accepted
Date:		Tue, 26 Jan 2010 14:13:35 -0500

	I am pleased to announce that the GCC Steering Committee has
accepted the contribution of the gccgo front-end and gcc-specific runtime
for the Go language with Ian Taylor appointed maintainer.  The GCC
Release Managers will decide the details about the timing of the merge and
inclusion in GCC 4.5 or later.

	Please join me in congratulating and thanking Ian and the Go
language developers.  Please update your listing in the MAINTAINERS file.

Happy hacking!
David

GCC to merge Go support

Posted Jan 27, 2010 16:27 UTC (Wed) by patrick_g (subscriber, #44470) [Link] (5 responses)

>>>The GCC Release Managers will decide the details about the timing of the merge and inclusion in GCC 4.5 or later.

Strange because GCC 4.5 is in regression and documentation fixes only.

GCC to merge Go support

Posted Jan 27, 2010 16:39 UTC (Wed) by nix (subscriber, #2304) [Link] (3 responses)

New frontends, if they aren't disruptive to the middle or back-end(s), are also fine in stage 3. If they're written by a longtime GCC maintainer, so much the better.

GCC to merge Go support

Posted Jan 27, 2010 17:30 UTC (Wed) by nix (subscriber, #2304) [Link] (2 responses)

Of course this requires -fsplit-stack support, so it *does* touch the middle-end...

GCC to merge Go support

Posted Jan 27, 2010 19:56 UTC (Wed) by rriggs (guest, #11598) [Link] (1 responses)

I had too Google -fsplit-stack, so I figure I'd post the results of what I found here:

http://www.pubbs.net/gcc/200910/10468/

GCC to merge Go support

Posted Jan 29, 2010 11:20 UTC (Fri) by Tobu (subscriber, #24111) [Link]

Here it is untruncated and from a less spammy source:
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00414.html

GCC to merge Go support

Posted Jan 27, 2010 16:40 UTC (Wed) by tshow (subscriber, #6411) [Link]

It does say the maintainers will decide where it will be merged in "version 4.5 or later". Which says to me it will almost certainly be "or later" unless the front-end is truly standalone and can be flagged as experimental.

Syntax flubs

Posted Jan 27, 2010 20:53 UTC (Wed) by ncm (guest, #165) [Link] (28 responses)

I guess this means it's too late to fix the pointer-dereference syntax. Go is (well, was) unique in that they can (could) change the language syntax any time they liked. They have a tool that can update all the code in their repository with the new syntax, and there's essentially no Go code not in the repository.

It makes some sense to copy C syntax when you have to read C header files. It is powerfully stupid to copy C syntax mistakes if you don't need to read C header files. (Yes, Java too.) One of the biggest C syntax mistakes was the prefix dereference operator. Pascal, of all languages, actually got dereference syntax right -- postfix dereference may be the only thing Pascal got right.

Of course there were numerous other C language syntax design mistakes. Perhaps the worst was the low precedence of bitwise operators, itself inherited from B (used to be there were no short-circuiting && or || operators, so bitwise was all you had), but there were lots of others. Declaration syntax was a problem, but Go partly fixed that one. Having fixed it, it's ridiculous not to fix others equally bad.

Syntax flubs

Posted Jan 27, 2010 20:57 UTC (Wed) by ikm (guest, #493) [Link] (27 responses)

> One of the biggest C syntax mistakes was the prefix dereference operator. Pascal, of all languages, actually got dereference syntax right -- postfix dereference may be the only thing Pascal got right.

Could you comment on why should postfix be deemed superior? I don't see much difference at the first glance.

Syntax flubs

Posted Jan 27, 2010 21:19 UTC (Wed) by alextingle (guest, #20593) [Link] (21 responses)

Because things like this make your head hurt...

*a.b->c.d->e *= *p->q.r * *x[2];

At least a postfix dereference operator goes next to the thing it's dereferencing.

Still not clear it's better

Posted Jan 27, 2010 21:30 UTC (Wed) by dwheeler (guest, #1216) [Link] (14 responses)

Yes, this can make your head hurt:
*a.b->c.d->e *= *p->q.r * *x[2];

But postfix isn't really much better (using ^):
a^.b->c.d->e *= p^->q.r * x[2]^;

But you can be consistent to make it clearer

Posted Jan 27, 2010 21:57 UTC (Wed) by felixfix (subscriber, #242) [Link] (1 responses)

a^.b^.c.d^.e *= p^^.q.r * x[2]^;

Still ugly, but then it's a twisted example meant to be ugly. That prefix * has always annoyed me.

But you can be consistent to make it clearer

Posted Jan 28, 2010 0:30 UTC (Thu) by elanthis (guest, #6227) [Link]

Is it the fact that's prefix or the fact that it's a * which is the same as
another very common operator?

Think carefully

Posted Jan 27, 2010 22:00 UTC (Wed) by ncm (guest, #165) [Link] (9 responses)

Postfix dereference is better precisely because dwheeler's mistaken interpretation is possible only with prefix dereference.

Relatedly, it means that the very common construction "(*ptr)->member" loses its parentheses: "ptr^->member", and there is no temptation to forget them and write something by accident that means "ptr->member^".

Think carefully

Posted Jan 27, 2010 22:41 UTC (Wed) by alextingle (guest, #20593) [Link]

Exactly!

Think carefully

Posted Jan 27, 2010 23:37 UTC (Wed) by nevyn (guest, #33129) [Link] (1 responses)

> Postfix dereference is better precisely because dwheeler's mistaken
> interpretation is possible only with prefix dereference.

You can always get it wrong:

while (*dst++ = *src++) ;

while (dst^++ = src^++) ;

...and:

++*dst;

++dst^;

...maybe if you are used to it, it does seem marginally better (and I guess both of the above postfix examples could give warnings). But IMO the much bigger win is to have something that 99.999% of the programmers on the planet will instantly understand (and make porting code easier), instead of having them say WTF!

Think carefully

Posted Jan 28, 2010 1:36 UTC (Thu) by droundy (subscriber, #4559) [Link]

Fortunately, these examples don't apply to go, since go lacks pointer
arithmetic. Also, the ++ operator is changed to a statement in go, also to
avoid this sort of confusion.

Think carefully

Posted Jan 28, 2010 2:12 UTC (Thu) by viro (subscriber, #7872) [Link] (5 responses)

This is complete BS; *p->field and (*p)->field _never_ will be both accepted by compiler - with the former p has to be a pointer to struct or union, while with the latter it has to be a pointer to pointer to struct or union. There's no chance whatsoever that such typo will not be caught as soon as e.g. i = 2 * (3 + 4(; would be.

Get yourself a better example...

Think carefully

Posted Jan 28, 2010 7:40 UTC (Thu) by ncm (guest, #165) [Link] (3 responses)

Examples are easy to concoct, but why should I have to wait for the compiler to tell me it's wrong, if a better notation means I don't get it wrong in the first place?

Think carefully

Posted Jan 28, 2010 20:32 UTC (Thu) by viro (subscriber, #7872) [Link] (2 responses)

Care to provide any evidence supporting the claim that this kind of braino is frequent? IME it is very low-frequency and my anecdotes are worth as much as yours (i.e. nothing).

FWIW, it _is_ resolvable - comparison of frequencies of {member(deref(deref(...))), postfix increment/decrement(deref(...))} with those of deref(prefix increment/prefix decrement(...)) would make a good first approximation. And that can be measured, unlike the frequencies of brainos averaged by programmers. Feel free to take gcc (or sparse, which is easier to hack) and add tree-walker that would count such nodes in expression trees. Run it on sufficiently large and diverse codebase and report the results. Hell, extend that to other combinations of operations, add analysis of number of parens needed with different choices of precedences, prefix vs. postfix, associativity and you've got a publishable paper out of it.

Without any kind of hard data it's basically YAHolyWar and as such its proper place is in alt.sex.masturbation, not here...

Think carefully

Posted Jan 28, 2010 22:32 UTC (Thu) by efexis (guest, #26355) [Link]

Here's more of a place for civilised discussion, and whilst it's obviously preferable to have subjectivity not given in the tone of objectivity (it can confuse those who are learning) it's also just as preferable to have disagreements given in a more agreeable tone than refering to someones opinions as "complete BS" :-p

Think carefully

Posted Jan 29, 2010 3:19 UTC (Fri) by ncm (guest, #165) [Link]

I see that you are not interested in a civilized discussion. Why post at all?

Irrelevant.

Posted Jan 28, 2010 8:34 UTC (Thu) by alextingle (guest, #20593) [Link]

Irrelevant. I can write a compiler for any convoluted syntax I care to conceive:

Whitespace
Brainfuck

Just because the compiler can parse it without ambiguity, doesn't make it a good choice of syntax.

Still not clear it's better

Posted Jan 28, 2010 13:13 UTC (Thu) by nlucas (guest, #33793) [Link] (1 responses)

Even better would be to do what D does. If you want a member of struct pointed by a pointer then it's no different from any other variable. Just use the . (dot).

Still not clear it's better

Posted Jan 28, 2010 15:31 UTC (Thu) by zmower (subscriber, #3005) [Link]

Ada also uses dot notation. You can do A.Field to implicitly access a field or A.all to explicitly deference an access type. We prefer := for assignment and = for comparison. Thankyou Pascal.

a.b.c.d.e := a.b.c.d.e * p.q.r * x(2).all;

Syntax flubs

Posted Jan 29, 2010 9:07 UTC (Fri) by dgm (subscriber, #49227) [Link] (5 responses)

>Because things like this make your head hurt...
>*a.b->c.d->e *= *p->q.r * *x[2];

Maybe the case for prefix operators is much more simple:

*a=b; /* ok */
a*=b; /* what should we do with this? */

Syntax flubs

Posted Jan 29, 2010 18:25 UTC (Fri) by tjc (guest, #137) [Link] (4 responses)

Yeah, that's a problem.

The issue isn't that postfix indirection is better than prefix; the real issue is that postfix declaration is better than prefix because then the pointer declarator is on the same precedence level as () and [], and complex declaration are less... complex. This is problematic in a language like C where declaration mimics use, since the best syntax for declaration is not the same as the best syntax for use.

Syntax flubs

Posted Jan 30, 2010 10:52 UTC (Sat) by ncm (guest, #165) [Link] (3 responses)

No, it is no problem. Of course Go is not bound to match C's operators in any
case, but if they chose to be so bound, they could use "@" for the purpose. As
could, indeed, C or C++. I.e., those languages could also fix the problem, even at
this late date. They can be excused for not doing so, but Go cannot.

Syntax flubs

Posted Feb 4, 2010 18:25 UTC (Thu) by tjc (guest, #137) [Link] (2 responses)

I agree, using '@' as an indirection operator would work. But it looks funny, especially as a postfix operator. I would probably get used to it.

I better like the idea of separating declaration syntax from expression syntax and using '*' as a postfix pointer declarator and '[]' as an infix[1] indirection operator, like this:

var p *[10]int;
var a [10]*int;

[p][0] = 1;
[a[0]] = 1;

I guess I could call this "square lisp" syntax. :)

[1] This really isn't infix, since the operand is infix, not the operator, but I don't know the correct term for this form.

Syntax flubs

Posted Feb 4, 2010 22:51 UTC (Thu) by anselm (subscriber, #2796) [Link] (1 responses)

[1] This really isn't infix, since the operand is infix, not the operator, but I don't know the correct term for this form.

Outfix?

Syntax flubs

Posted Feb 7, 2010 1:44 UTC (Sun) by tjc (guest, #137) [Link]

Outfix?

You are indeed correct!

http://www.abstractmath.org/MM/MMFunctionValue.htm#_Toc223234910

It seems obvious in retrospect. Thanks.

Syntax flubs

Posted Jan 28, 2010 2:15 UTC (Thu) by HelloWorld (guest, #56129) [Link] (3 responses)

It makes the declaration syntax much easier. The C syntax for declarations is derived from the syntax for expressions. For example, int *i[10]; actually means "you can take the 10th element of i (well, almost) and then dereference it and you get an int". If you want to declare a pointer to an array of 10 ints, you need to dereference first, thus you have to write int (*i)[10];. With a postfix dereferencing operator, you could get rid of the parenthesis. It would then be int i*;[10] for an array of 10 pointers to int and int i[10]* for a pointer to an array of 10 ints. One could take that even further and put the type behind the variable name in simple declarations such as i int;, as opposed to int i;. Naturally, one would then declare a function returning int (taking no arguments) thus: i int(void). That would make the function pointer syntax easier. Consider for example this C prototype:void (*signal(int sig, void (*func)(int)))(int);. This is so ugly that it's often written with a typedef: typedef void (*sighandler_t)(int); sighandler_t signal(int, sighandler_t) If you put the type behind the name and use a postfix dereferencing operator, you'll get signal (int)void*(int, (int)void*). I find this much much more readable than the C version. I didn't think this through very thoroughly. Perhaps this leads to syntax ambiguities, but so far i couldn't find any...

Syntax flubs

Posted Jan 28, 2010 2:19 UTC (Thu) by HelloWorld (guest, #56129) [Link] (1 responses)

Sorry, there was a typo. I meant to write <tt>i*[10]</tt>, not <tt>i*;[10]</tt>.

Syntax flubs

Posted Jan 28, 2010 2:20 UTC (Thu) by HelloWorld (guest, #56129) [Link]

I probably shouldn't be writing comments at this time at all...

Syntax flubs

Posted Jan 29, 2010 11:57 UTC (Fri) by mpr22 (subscriber, #60784) [Link]

My instinct is that a function pointer with fully typed arguments - while providing an excellent example of how C's syntax for pointers can be very confusing - is in any event a complex enough data type to deserve its own type declaration separate from the declaration of any objects of that type.

Syntax flubs

Posted Jan 28, 2010 17:09 UTC (Thu) by tjc (guest, #137) [Link]

Could you comment on why should postfix be deemed superior?

You didn't ask me, but that didn't stop anyone else, so here I go. :-)

As a real-world example, here's the prototype for the Unix signal function:

void (*signal(int sig, void (*disp)(int)))(int);

Here it is again with postfix pointer notation:

void signal(int sig, void disp*(int)) *(int);

This is left-to-right-- with the exception of the base types-- so it's easier to read, at least for me.

Here it is again, with the base types left-to-right:

func signal(sig int, disp*(int) void) *(int) void;

This requires using a declarator like "func" so that the parser can figure out what is going on.