| |||||||||||||
Syntax flubsSyntax flubsPosted Jan 27, 2010 21:19 UTC (Wed) by alextingle (guest, #20593)In reply to: Syntax flubs by ikm Parent article: GCC to merge Go support
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.
(Log in to post comments)
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.
|
|||||||||||||