| |||||||||||||
Syntax flubsSyntax flubsPosted Jan 27, 2010 20:53 UTC (Wed) by ncm (subscriber, #165)Parent article: GCC to merge Go support 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.
(Log in to post comments)
Syntax flubs Posted Jan 27, 2010 20:57 UTC (Wed) by ikm (subscriber, #493) [Link]
> 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]
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]
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 ^):
But you can be consistent to make it clearer Posted Jan 27, 2010 21:57 UTC (Wed) by felixfix (subscriber, #242) [Link]
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 (subscriber, #165) [Link]
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 23:37 UTC (Wed) by nevyn (subscriber, #33129) [Link]
> 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]
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 (subscriber, #165) [Link]
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]
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 (subscriber, #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: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 (subscriber, #33793) [Link]
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]
>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 */
Syntax flubs Posted Jan 29, 2010 18:25 UTC (Fri) by tjc (subscriber, #137) [Link] 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 (subscriber, #165) [Link]
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 (subscriber, #137) [Link] 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] 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 (subscriber, #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] 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]
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 (subscriber, #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.
|
|||||||||||||