www.digitalmars.com         C & C++   DMDScript  

D - operator precidence/boolean expr

reply Mike Wynn <mike l8night.co.uk> writes:
  how should the following be eval'd ?

   `foo & 0xFFFF != 0xFFFF` ? (foo is uint)

it appears to be eval'd as foo & (0xFFFF != 0xFFFF)
as opposed to what I wanted to write `(foo & 0xFFFF) != 0xFFFF`

if the latter then there is a bug in 0.71 linux DMD
if the former, then I think D should issue expr is always false errors

if ( foo & 0xFFFF != 0xFFFF ) {
	// no warnings no errors but this code will never run.
}
Sep 08 2003
parent reply "Walter" <walter digitalmars.com> writes:
It's the C operator precedence rules at work <g>.

"Mike Wynn" <mike l8night.co.uk> wrote in message
news:bjii64$1di3$1 digitaldaemon.com...
   how should the following be eval'd ?

    `foo & 0xFFFF != 0xFFFF` ? (foo is uint)

 it appears to be eval'd as foo & (0xFFFF != 0xFFFF)
 as opposed to what I wanted to write `(foo & 0xFFFF) != 0xFFFF`

 if the latter then there is a bug in 0.71 linux DMD
 if the former, then I think D should issue expr is always false errors

 if ( foo & 0xFFFF != 0xFFFF ) {
 // no warnings no errors but this code will never run.
 }

Sep 09 2003
parent reply John Boucher <John_member pathlink.com> writes:
Ew, I never knew that, but being the type who puts in more parentheses than
necessary I never experience that problem. I think now would be a good time to
fix the situation, bitwise operations should be higher precedence than
comparison. D _is_ breaking away from the bad parts of C right?

In article <bjmflf$1184$1 digitaldaemon.com>, Walter says...
It's the C operator precedence rules at work <g>.

"Mike Wynn" <mike l8night.co.uk> wrote in message
news:bjii64$1di3$1 digitaldaemon.com...
   how should the following be eval'd ?

    `foo & 0xFFFF != 0xFFFF` ? (foo is uint)

 it appears to be eval'd as foo & (0xFFFF != 0xFFFF)
 as opposed to what I wanted to write `(foo & 0xFFFF) != 0xFFFF`

 if the latter then there is a bug in 0.71 linux DMD
 if the former, then I think D should issue expr is always false errors

 if ( foo & 0xFFFF != 0xFFFF ) {
 // no warnings no errors but this code will never run.
 }


John Boucher The King had Humpty pushed.
Sep 10 2003
next sibling parent reply Mike Wynn <mike l8night.co.uk> writes:
John Boucher wrote:
 Ew, I never knew that, but being the type who puts in more parentheses than
 necessary I never experience that problem. I think now would be a good time to
 fix the situation, bitwise operations should be higher precedence than
 comparison. D _is_ breaking away from the bad parts of C right?
 

the array declare has been changed ... (at first it drove me nuts but I'm a big fan now). I think the precidence should be (roughly) . -> [] ++ -- ! - cast // so cast(T)a.foo() is cast(T)(a.foo()) like java // not (cast(T)a).foo(); // or have a low presidence cast `as` // as(T)foo.s() => cast(T)(foo.s()) * / % + - & | ^ < > <= >= == != === !=== <>! etc && || // you could add and, or, xor as low pres operator // or have and, or, xor as high pres boolean operators.
 In article <bjmflf$1184$1 digitaldaemon.com>, Walter says...
 
It's the C operator precedence rules at work <g>.

"Mike Wynn" <mike l8night.co.uk> wrote in message
news:bjii64$1di3$1 digitaldaemon.com...

  how should the following be eval'd ?

   `foo & 0xFFFF != 0xFFFF` ? (foo is uint)

it appears to be eval'd as foo & (0xFFFF != 0xFFFF)
as opposed to what I wanted to write `(foo & 0xFFFF) != 0xFFFF`

if the latter then there is a bug in 0.71 linux DMD
if the former, then I think D should issue expr is always false errors

if ( foo & 0xFFFF != 0xFFFF ) {
// no warnings no errors but this code will never run.
}


John Boucher The King had Humpty pushed.

Sep 10 2003
parent Ilya Minkov <minkov cs.tum.edu> writes:
Mike Wynn wrote:
 I think the precidence should be (roughly)

 // so cast(T)a.foo() is cast(T)(a.foo()) like java
 // not (cast(T)a).foo();
 // or have a low presidence cast `as`
 // as(T)foo.s() => cast(T)(foo.s())

You are right. Transferring Java code to D would add it quite some value - esp. considering casting in that form is far more frequent in Java than in C. I guess even the C rule probably made sense in some early variants of C, and was left as it was further on... Like, today's C programs are fairly type-safe, hardly anyone can afford coding in C without prototypes without his head being knocked off. :) -eye
Sep 11 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"John Boucher" <John_member pathlink.com> wrote in message
news:bjnh5b$2fim$1 digitaldaemon.com...
 Ew, I never knew that, but being the type who puts in more parentheses

 necessary I never experience that problem. I think now would be a good

 fix the situation, bitwise operations should be higher precedence than
 comparison. D _is_ breaking away from the bad parts of C right?

D doesn't change the operator precedence rules from C/C++ because it would subtly and silently screw up code that was transferred between the languages. It also causes haywire in peoples' thinking. For example, in England, they drive on the wrong (!) side of the road. I found that when I step into the street, I look to my left for cars, and then get promptly run over by a car coming from the right. My thinking got so screwed up I decided to stop trying to remember which rule to apply and look both ways. I had similar problems using the inline assembler in gcc, which reverses the arguments. It just makes my eyeballs hurt looking at it, I am so used to the Intel syntax.
Sep 10 2003
next sibling parent reply Mike Wynn <mike l8night.co.uk> writes:
Walter wrote:
 "John Boucher" <John_member pathlink.com> wrote in message
 news:bjnh5b$2fim$1 digitaldaemon.com...
 
Ew, I never knew that, but being the type who puts in more parentheses

than
necessary I never experience that problem. I think now would be a good

time to
fix the situation, bitwise operations should be higher precedence than
comparison. D _is_ breaking away from the bad parts of C right?

D doesn't change the operator precedence rules from C/C++ because it would subtly and silently screw up code that was transferred between the languages. It also causes haywire in peoples' thinking. For example, in England, they drive on the wrong (!) side of the road. I found that when I step into the street, I look to my left for cars, and then get promptly run over by a car coming from the right. My thinking got so screwed up I decided to stop trying to remember which rule to apply and look both ways. I had similar problems using the inline assembler in gcc, which reverses the arguments. It just makes my eyeballs hurt looking at it, I am so used to the Intel syntax.

In England/Japan/Oz you drive on the left, drive the car from the righthand side. In Europe/America drive on right, sit on left. it's not so hard, (once you stop hitting the window ever time you want to change gear)[at least the pedal are in the same order] and remember which way to look when joining the freeway/autobahn/motorway in case there is a lorry/truck/juggernaut already there! (roundabouts go about round that was fun!) and crossroads where even more confusing in a righthand drive car in Germany. to make and array with is index as a[0 to 4][0 to 5] C: int a[4][5]; Java: int[][] a = new int[4][5]; D: int[5][4] a; or int[][] a = new int[5][4]; // I believe not checked. Pascal : var a : array(0 to 4) of array(0 to 5) of integer; cast: to cast the return from an assoc array to an different type; Java: MyObj func( Hashtable h, String tag ) { return (MyObj)h.get( tag ); } pseudo C++: MyObj & func( Hashtable & h, char * tag ) { return (MyObj&)(h.get( tag )); } D: MyObj & func( Object[char[]] & h, char[] tag ) { return (MyObj)(h[tag]); } we're already driving sideways down the center line! if ( a + b < 3 ) { ... } is if ( (a+b) < 3 ) { ... } why not make if ( a & b < 3 ) { ... } the more logical if ( (a&b) < 3 ) { ... } instead of the useless if ( a & (b < 3 ) { ... } if you realy meant the later a is obviously a boolean so it should be instead of the useless if ( a && b < 3 ) { ... } (having && as lower than comparison makes sence) I know <bool-a> & <bool-b> can be used to replace <bool-a> && <bool-b> then you want to force the eval of <bool-b> i.e. if ( a & (b++ < 3) ) { ... } NOT the same as if ( a && (b++ < 3) ) { ... } as `b++` is eval'ed in the former, but that's (imho) nasty code. every algo based lang as a subtle difference from all the others the array declare order annoyed me for a day or two ... but I'm a fan now that I've actually used it. I believe reordering the operator precidence would be a benifit gas/intel is not too bad most of the time you can just about have separate op codes (movl not mov) and gas uses % mov eax, esp => eax:=esp movl %eax, %esp => esp:=eax I found doing perl and C together was not too hard, doing perl and php at the same time got me confused. (not that i'm sugesting that we prefix all vars with for visual indication, [I have a separate syntax highlighting colour scheme for each language which helps a lot]) conclusion ... do the right thing not the easy thing D already has lots of subtle changes from C, one more it not going to make porting C to D any harder.
Sep 11 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Mike Wynn" <mike l8night.co.uk> wrote in message
news:bjq3ds$30qs$1 digitaldaemon.com...
necessary I never experience that problem. I think now would be a good



fix the situation, bitwise operations should be higher precedence than
comparison. D _is_ breaking away from the bad parts of C right?

D doesn't change the operator precedence rules from C/C++ because it


 subtly and silently screw up code that was transferred between the
 languages. It also causes haywire in peoples' thinking. For example, in
 England, they drive on the wrong (!) side of the road. I found that when


 step into the street, I look to my left for cars, and then get promptly


 over by a car coming from the right. My thinking got so screwed up I


 to stop trying to remember which rule to apply and look both ways.

conclusion ... do the right thing not the easy thing D already has lots of subtle changes from C, one more it not going to make porting C to D any harder.

If you keep too many of C's problems, people won't have reason enough to upgrade to D. ;) People can adapt. I expect this change would break very very little legit C code. Sean
Sep 11 2003
parent reply John Boucher <John_member pathlink.com> writes:
In article <bjq7ph$5uf$1 digitaldaemon.com>, Sean L. Palmer says...
"Mike Wynn" <mike l8night.co.uk> wrote in message
news:bjq3ds$30qs$1 digitaldaemon.com...
necessary I never experience that problem. I think now would be a good



fix the situation, bitwise operations should be higher precedence than
comparison. D _is_ breaking away from the bad parts of C right?

D doesn't change the operator precedence rules from C/C++ because it


 subtly and silently screw up code that was transferred between the
 languages. It also causes haywire in peoples' thinking. For example, in
 England, they drive on the wrong (!) side of the road. I found that when


 step into the street, I look to my left for cars, and then get promptly


 over by a car coming from the right. My thinking got so screwed up I


 to stop trying to remember which rule to apply and look both ways.

conclusion ... do the right thing not the easy thing D already has lots of subtle changes from C, one more it not going to make porting C to D any harder.

If you keep too many of C's problems, people won't have reason enough to upgrade to D. ;) People can adapt. I expect this change would break very very little legit C code. Sean

Indeed, how often is such an expression used? And of those times, how often would there not already be parentheses around the part that should have precedence? In such cases, the change would not cause trouble. I for one would always put in the parentheses whether required or not. One of the reasons for putting in the (otherwise unnecessary) parentheses is to make it clear to anyone reading the code what is intended, that's just good coding practice. <g>Of course, a language could enforce such good coding practice by not having any precedence of operations, there's definitely some value to that.</g> This topic would not have been brought up if there were not so many of us who find this behaviour unexpected. I suppose if someone can track down why the order of precedence was made the way it is in C to begin with it may shed some light on the situation. It seems to me that fixing the situation and documenting it well is the way to go. After all, the specification already has a section on the differences between the languages. Furthermore, how many ports of C to D will blow up on a printf() that doesn't have a ".*" added to a string format? Yeah, I know, that causes a more noticable and more easily tracked-down problem, as opposed to "subtly and silently" as you say. But it's likely to cost far more people far more hours of labor. (Perhaps this is an example of what my last supervisor called my being "argumentative" just before I got laid off.) John Boucher The King had Humpty pushed.
Sep 11 2003
parent reply "Walter" <walter digitalmars.com> writes:
"John Boucher" <John_member pathlink.com> wrote in message
news:bjqs2j$11qv$1 digitaldaemon.com...
 In article <bjq7ph$5uf$1 digitaldaemon.com>, Sean L. Palmer says...
 conclusion ... do the right thing not the easy thing D already has lots
 of subtle changes from C, one more it not going to make porting C to D
 any harder.

upgrade to D. ;) People can adapt. I expect this change would break very very little


code.


In general I agree with you, but not on the operator precedence thing.
 Indeed, how often is such an expression used? And of those times, how

 would there not already be parentheses around the part that should have
 precedence? In such cases, the change would not cause trouble. I for one

 always put in the parentheses whether required or not. One of the reasons

 putting in the (otherwise unnecessary) parentheses is to make it clear to

 reading the code what is intended, that's just good coding practice.

It would be ok to change it if it was an obvious change that would result in compilation errors if used the C way. But that isn't the case here - the equation will subtly and silently break. This is not a good idea when moving over a complicated expression from some C code.
 <g>Of course, a language could enforce such good coding practice by not

 any precedence of operations, there's definitely some value to that.</g>

Then you wind up with Lots of Infernally Stupid Parentheses (LISP) <g>.
 This topic would not have been brought up if there were not so many of us

 find this behaviour unexpected. I suppose if someone can track down why

 order of precedence was made the way it is in C to begin with it may shed

 light on the situation.

I view it like the QWERTY keyboard. Sure, the Dvorak layout makes more sense, but who wants to retrain their fingers like that? Even if one wanted to, in the process there'd be innumerable frustrating typos. And then when you had to write a bit of C code maintenance, you're bollixed again.
 It seems to me that fixing the situation and documenting it well is the

 go. After all, the specification already has a section on the differences
 between the languages.

Few will read the documentation thoroughly, and even if they did, it takes an expert to learn all the subtleties of any language. Better to have it work as expected.
 Furthermore, how many ports of C to D will blow up on a printf() that

 have a ".*" added to a string format? Yeah, I know, that causes a more

 and more easily tracked-down problem, as opposed to "subtly and silently"

 say. But it's likely to cost far more people far more hours of labor.

You're right on that, but the solution there is to write a D printf. It's on the drawing board, just haven't done it yet.
 (Perhaps this is an example of what my last supervisor called my being
 "argumentative" just before I got laid off.)

LOL! You should see what routinely got written on my job performance reviews.
Sep 11 2003
next sibling parent reply John Boucher <John_member pathlink.com> writes:
OK, but if bool were strongly typed, it _should_ cause a compilation error,
shouldn't it? Even if unnecessary parentheses were used in the original:
( X & ( Y != Z ) )

Perhaps this is reason enough to strongly type bool? wink wink nudge nudge

In article <bjr193$1981$1 digitaldaemon.com>, Walter says...
It would be ok to change it if it was an obvious change that would result in
compilation errors if used the C way. But that isn't the case here - the
equation will subtly and silently break. This is not a good idea when moving
over a complicated expression from some C code.

John Boucher The King had Humpty pushed
Sep 11 2003
parent reply Mike Wynn <mike l8night.co.uk> writes:
John Boucher wrote:
 OK, but if bool were strongly typed, it _should_ cause a compilation error,
 shouldn't it? Even if unnecessary parentheses were used in the original:
 ( X & ( Y != Z ) )
 

not is X was a bool :(
Sep 11 2003
parent reply John Boucher <John_member pathlink.com> writes:
Ah, but not if bools are strongly typed such that bitwise operations are illegal
as suggested by someone else last week.

The logical operators should only work for bool expressions, the bitwise
operators should only work for non-bool expressions.

And, having grown up in Boston, I _always_ look both ways before crossing a
street, one way or not. After all, I too have driven the wrong way on a one way
street.

In article <bjrf3n$1rpd$2 digitaldaemon.com>, Mike Wynn says...
John Boucher wrote:
 OK, but if bool were strongly typed, it _should_ cause a compilation error,
 shouldn't it? Even if unnecessary parentheses were used in the original:
 ( X & ( Y != Z ) )
 

not is X was a bool :(

John Boucher The King had Humpty pushed.
Sep 12 2003
parent reply Mike Wynn <mike l8night.co.uk> writes:
John Boucher wrote:
 Ah, but not if bools are strongly typed such that bitwise operations are
illegal
 as suggested by someone else last week.
 
 The logical operators should only work for bool expressions, the bitwise
 operators should only work for non-bool expressions.

but the rhs of && or || does not need to be evaluated with & and | both lhs and rhs are evaluated so `if ( ((s = foo()) === null) & ((b = bar()) === null) )` is not the same as `if ( ((s = foo()) === null) && ((b = bar()) === null) )` <bool> && <bool> is not quite <bool>& <bool> also why should bitwise ops not work on bits and bools?
Sep 12 2003
parent reply John Boucher <John_member pathlink.com> writes:
Oh, yeah. Dang! I forgot about the shortcutting inherent in the bitwise
operators. Well, rather than suggest a &&& operator, I'll take a nap and think
about it.

In article <bjsv4d$t5t$1 digitaldaemon.com>, Mike Wynn says...
John Boucher wrote:
 Ah, but not if bools are strongly typed such that bitwise operations are
illegal
 as suggested by someone else last week.
 
 The logical operators should only work for bool expressions, the bitwise
 operators should only work for non-bool expressions.

but the rhs of && or || does not need to be evaluated with & and | both lhs and rhs are evaluated so `if ( ((s = foo()) === null) & ((b = bar()) === null) )` is not the same as `if ( ((s = foo()) === null) && ((b = bar()) === null) )` <bool> && <bool> is not quite <bool>& <bool> also why should bitwise ops not work on bits and bools?

John Boucher The King had Humpty pushed.
Sep 12 2003
parent John Boucher <John_member pathlink.com> writes:
OK, I've had my nap... well actually I didn't, I simply took my son to the park.

Anyway... No need to reorder the precedence. Just strongly type bool.
The precedence order is correct for bools already. And with non-bools it's
unlikely or hopefully erroneous to use comparison operators so the precedence
won't matter.

Going back to
if ( X & Y != Z )
X must be bool or there will be a compilation error because the comparison
operator (which has precedence) will always produce a bool could only be &ed
with another bool.

If X (and Y) is not bool then the programmer more likely meant
if ( ( X & Y ) != Z )
and will need to add the parentheses to say so.

So I'll shut up now... about this anyway. :)

In article <bjt0q3$vek$1 digitaldaemon.com>, John Boucher says...
Oh, yeah. Dang! I forgot about the shortcutting inherent in the bitwise
operators. Well, rather than suggest a &&& operator, I'll take a nap and think
about it.

In article <bjsv4d$t5t$1 digitaldaemon.com>, Mike Wynn says...
John Boucher wrote:
 Ah, but not if bools are strongly typed such that bitwise operations are
illegal
 as suggested by someone else last week.
 
 The logical operators should only work for bool expressions, the bitwise
 operators should only work for non-bool expressions.

but the rhs of && or || does not need to be evaluated with & and | both lhs and rhs are evaluated so `if ( ((s = foo()) === null) & ((b = bar()) === null) )` is not the same as `if ( ((s = foo()) === null) && ((b = bar()) === null) )` <bool> && <bool> is not quite <bool>& <bool> also why should bitwise ops not work on bits and bools?

John Boucher The King had Humpty pushed.

John Boucher The King had Humpty pushed.
Sep 12 2003
prev sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 <g>Of course, a language could enforce such good coding practice by not

 any precedence of operations, there's definitely some value to that.</g>


Why is this in a grin. This seems like a profoundly good idea. Of course, I'm not a compiler writer, but you'd have to show me examples to prove the badness of the notion.
Sep 12 2003
next sibling parent "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bjs0ip$2lc3$1 digitaldaemon.com...
 <g>Of course, a language could enforce such good coding practice by



 having
 any precedence of operations, there's definitely some value to



 Why is this in a grin. This seems like a profoundly good idea.

 Of course, I'm not a compiler writer, but you'd have to show me examples

 prove the badness of the notion.

I think there have been languages that did that (APL?) that were not successful. People are simply too used to a+b*c being (a+(b*c)) rather than ((a+b)*c).
Sep 12 2003
prev sibling parent reply Mike Wynn <mike l8night.co.uk> writes:
Matthew Wilson wrote:
<g>Of course, a language could enforce such good coding practice by not

having
any precedence of operations, there's definitely some value to that.</g>


Why is this in a grin. This seems like a profoundly good idea. Of course, I'm not a compiler writer, but you'd have to show me examples to prove the badness of the notion.

`c = a.foo( e, f ) + b[7]` ?? `(c = (((a.foo)( e, f )) + b))[7]` ?? if you want brackets everywhere use lisp, as its prefix there is not opertor precidence (= c (+ a (* b c ))
Sep 12 2003
parent Derek Parnell <Derek.Parnell No.Spam> writes:
On Fri, 12 Sep 2003 18:39:23 +0100 (09/13/03 03:39:23)
, Mike Wynn <mike l8night.co.uk> wrote:

 Matthew Wilson wrote:
 <g>Of course, a language could enforce such good coding practice by 
 not

having
 any precedence of operations, there's definitely some value to 
 that.</g>


Why is this in a grin. This seems like a profoundly good idea. Of course, I'm not a compiler writer, but you'd have to show me examples to prove the badness of the notion.

`c = a.foo( e, f ) + b[7]` ?? `(c = (((a.foo)( e, f )) + b))[7]` ?? if you want brackets everywhere use lisp, as its prefix there is not opertor precidence (= c (+ a (* b c ))

If you want people to unambiguously understand your intentions, use brackets. -- Derek -- Derek
Sep 14 2003
prev sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 D doesn't change the operator precedence rules from C/C++ because it would
 subtly and silently screw up code that was transferred between the
 languages. It also causes haywire in peoples' thinking. For example, in
 England, they drive on the wrong (!) side of the road. I found that when I
 step into the street, I look to my left for cars, and then get promptly

 over by a car coming from the right. My thinking got so screwed up I

 to stop trying to remember which rule to apply and look both ways.

He he. Well, given the fact that the majority of the world's population is right-handed, it is actually correct to have right-hand-drive cars, and therefore to drive on the left. Think about it... As for your problems, I can only smile. You guys in the US are too much ensconced in the "one-way of doing things". In this particular case, I can recall a time when I drove (right-hand drive) 200 miles from Manchester to London, got on a plane, flew to Nice (2hrs) and then drove (left-hand drive) a hire car from Nice to Briancon, and the brain didn't skip a beat. The one scary moment was halfway through the French half of the journey when I though to myself "I should be finding this weird!", and then had a, thankfully resistible, urge to cross over the road. As for operator precedence, I don't even know them, because I always use braces. :) Cosmopolitan Clive
Sep 11 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bjr35f$1bsg$1 digitaldaemon.com...
 As for operator precedence, I don't even know them, because I always use
 braces.

I.e. you can't remember it either and so look both ways before stepping into the street <g>. Q.E.D.
Sep 11 2003
next sibling parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Walter" <walter digitalmars.com> ha scritto nel messaggio
news:bjrer8$1rgd$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bjr35f$1bsg$1 digitaldaemon.com...
 As for operator precedence, I don't even know them, because I always use
 braces.

I.e. you can't remember it either and so look both ways before stepping

 the street <g>. Q.E.D.

Before crossing a one-way street, you only have to look in one direction, but it's not necessarily the way you use to look first... (and John Boucher thinks *he* is argumentative :-) ) OK guys, back to serious speaking (more or less): AFAIK, code readability and general good programming practice require to use parentheses to disambiguate C expressions containing logical boolean operators, so existing well-written C code shoudn't suffer too much from a good rationalization of operator precedence. OTOH, this is just theory, and it is true that perfectly legal C code would go toast before you can smell it. Nonetheless, I'd go for the change: Lots of Infernally Stupid Parentheses is what I often think when writing if's in C, more often than when I used LISP. <div disclaimer="Just kidding..." offsense-intended="0" take-it-seriously="no"> <img src="Walter_proudly_showing_his_OCCC_award.jpg" alt="Would you take language specifications from this man?"> </div> Ric
Sep 12 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message
news:bjs01t$2knj$1 digitaldaemon.com...
 <div disclaimer="Just kidding..." offsense-intended="0"
 take-it-seriously="no">
 <img src="Walter_proudly_showing_his_OCCC_award.jpg" alt="Would you take
 language specifications from this man?">
 </div>

LOL! You have to know how to do it very badly in order to know how to do it right!
Sep 12 2003
parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Walter" <walter digitalmars.com> ha scritto nel messaggio
news:bjss90$p72$1 digitaldaemon.com...
 LOL! You have to know how to do it very badly in order to know how to do

 right!

Right said! At least in OCCCs, where you _know_ you're doing it badly. Ain't you curious about what's gonna come up at the first ODCC? :-) Ric
Sep 15 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message
news:bk3r6d$178v$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> ha scritto nel messaggio
 news:bjss90$p72$1 digitaldaemon.com...
 LOL! You have to know how to do it very badly in order to know how to do

 right!

Right said! At least in OCCCs, where you _know_ you're doing it badly. Ain't you curious about what's gonna come up at the first ODCC? :-)

There won't be any preprocessor abuse!
Sep 17 2003
next sibling parent John Boucher <John_member pathlink.com> writes:
In article <bka995$2tgf$1 digitaldaemon.com>, Walter says...
"Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message
news:bk3r6d$178v$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> ha scritto nel messaggio
 news:bjss90$p72$1 digitaldaemon.com...
 LOL! You have to know how to do it very badly in order to know how to do

 right!

Right said! At least in OCCCs, where you _know_ you're doing it badly. Ain't you curious about what's gonna come up at the first ODCC? :-)

There won't be any preprocessor abuse!

Oh yeah? Just watch me! Maybe I can use HTML for text replacement too! John Boucher -- Quite contrary The King had Humpty pushed
Sep 17 2003
prev sibling next sibling parent "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Walter" <walter digitalmars.com> ha scritto nel messaggio
news:bka995$2tgf$1 digitaldaemon.com...
 "Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message
 news:bk3r6d$178v$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> ha scritto nel messaggio
 news:bjss90$p72$1 digitaldaemon.com...
 Ain't you curious about what's gonna come up at the first ODCC? :-)

There won't be any preprocessor abuse!

You bet! You just can't abuse what's not there... :) That's one of the coolest things about D IMO. Ric
Sep 17 2003
prev sibling parent Andy Friesen <andy ikagames.com> writes:
Walter wrote:

 There won't be any preprocessor abuse!

That sounds suspiciously like a bet to me.
Sep 18 2003
prev sibling next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
Touche!

I want to echo, and maybe amplify, John Boucher, and resurrect my request
that all conditional expressions and sub-expressions must be explicitly
boolean. i.e. the following would not compile:

  int i;
  long j;

  if( !i || j) // Filthy stuff!

and would have to be formed as

  if (i == 0 || j != 0)

I know this is less likely to get in than I am to get an award for
prosyletisation of C++'s iostreams, but what the hell! I'm someone that
writes code with the intention that it will live a long time, so I'm far
more interested in maintainability than in easy of first writing. It never
ceases to surprise me what little (overt at least) import this gets around
here. Sob sob. (Actually, to be fair, there seems to be precious little
interest in maintainability in any other newsgroups that I can see, so maybe
I need to take my little friend back indoors where its warm.)


"Walter" <walter digitalmars.com> wrote in message
news:bjrer8$1rgd$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bjr35f$1bsg$1 digitaldaemon.com...
 As for operator precedence, I don't even know them, because I always use
 braces.

I.e. you can't remember it either and so look both ways before stepping

 the street <g>. Q.E.D.

Sep 12 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bjs0em$2l8t$2 digitaldaemon.com...
 Touche!

 I want to echo, and maybe amplify, John Boucher, and resurrect my request
 that all conditional expressions and sub-expressions must be explicitly
 boolean. i.e. the following would not compile:

   int i;
   long j;

   if( !i || j) // Filthy stuff!

 and would have to be formed as

   if (i == 0 || j != 0)

 I know this is less likely to get in than I am to get an award for
 prosyletisation of C++'s iostreams, but what the hell! I'm someone that
 writes code with the intention that it will live a long time, so I'm far
 more interested in maintainability than in easy of first writing. It never
 ceases to surprise me what little (overt at least) import this gets around
 here. Sob sob. (Actually, to be fair, there seems to be precious little
 interest in maintainability in any other newsgroups that I can see, so

 I need to take my little friend back indoors where its warm.)

I don't see it as more maintainable, just more typing <g>. It's a C idiom I'm nearly as used to as my right thumb, and so I don't see the problem with it. The C idiom that causes trouble is: if (a = b) and that *is* illegal in D because it's almost always a typo.
Sep 12 2003
parent reply John Boucher <John_member pathlink.com> writes:
In article <bjss90$p72$2 digitaldaemon.com>, Walter says...
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bjs0em$2l8t$2 digitaldaemon.com...
 Touche!

 I want to echo, and maybe amplify, John Boucher, and resurrect my request
 that all conditional expressions and sub-expressions must be explicitly
 boolean. i.e. the following would not compile:

   int i;
   long j;

   if( !i || j) // Filthy stuff!

 and would have to be formed as

   if (i == 0 || j != 0)

 I know this is less likely to get in than I am to get an award for
 prosyletisation of C++'s iostreams, but what the hell! I'm someone that
 writes code with the intention that it will live a long time, so I'm far
 more interested in maintainability than in easy of first writing. It never
 ceases to surprise me what little (overt at least) import this gets around
 here. Sob sob. (Actually, to be fair, there seems to be precious little
 interest in maintainability in any other newsgroups that I can see, so

 I need to take my little friend back indoors where its warm.)

I don't see it as more maintainable, just more typing <g>. It's a C idiom I'm nearly as used to as my right thumb, and so I don't see the problem with it. The C idiom that causes trouble is: if (a = b) and that *is* illegal in D because it's almost always a typo.

"almost always" ? So then what do I do when I really _do_ want to do that (not that I ever do)? If bool is strongly typed, then if (a = b) will fail except when a and b are both bools. So what do we do then? Is it simply that the parser (or whatever) is checking for the assignment operator within a boolean expression? I mean this has to affect while and for loops too right? Although I understand the reasoning, I don't think you should make the rule affect only a very specific problem. Shouldn't it mean that _no_ form of assignment is allowed in a boolean expression? But it's not that assignment in a boolean expression is necessarily bad anyway, so why make it illegal? Perhaps a better idea would be to use the Pascal assignment operator := and make a bare equal sign an illegal token? I know, I know, it would cause a lot more work in porting C to D, but it's one of the things that could be automated with a script, like adding a .* to a printf. Can I hear an "amen"? John Boucher The King had Humpty pushed.
Sep 12 2003
parent reply "Walter" <walter digitalmars.com> writes:
"John Boucher" <John_member pathlink.com> wrote in message
news:bjsvcu$tha$1 digitaldaemon.com...
 In article <bjss90$p72$2 digitaldaemon.com>, Walter says...
The C idiom that causes trouble is:
    if (a = b)
and that *is* illegal in D because it's almost always a typo.


 that I ever do)?

a = b; if (a) or: if ((a = b) != 0)
 Is it simply that the parser (or whatever) is checking for the assignment
 operator within a boolean expression?

As the top level operator in a boolean expression, yes.
 I mean this has to affect while and for
 loops too right?

Yes.
 Although I understand the reasoning, I don't think you should
 make the rule affect only a very specific problem. Shouldn't it mean that

 form of assignment is allowed in a boolean expression?

No, as ((a = b) != 0) is almost never a typo. It's a common C idiom, too.
 But it's not that assignment in a boolean expression is necessarily bad

 so why make it illegal?

Because it's a common, and hard to find, mistake to type if (a = b) when one really meant if (a = = b).
 Perhaps a better idea would be to use the Pascal
 assignment operator := and make a bare equal sign an illegal token? I

 know, it would cause a lot more work in porting C to D, but it's one of

 things that could be automated with a script, like adding a .* to a

The Pascal := would be a workable alternative, but I like the less-typing = <g>.
 Can I hear an "amen"?

Can I say "ahh-hmm" instead? <grin>
Sep 13 2003
parent reply John Boucher <John_member pathlink.com> writes:
I just found that the following works too, but it's still ugly:

int x = 0 ;
int y = 1 ;

if ( x = y , x )
{
printf ( "\n%d" , x ) ;
}

And take a look at:

int x = 0 ;
int y = 1 ;
int z = 0 ;

if ( x = y , z = y )
{
printf ( "\n%d" , x ) ;
printf ( "\n%d" , z ) ;
}

which succeeds as well. Is this because you don't expect a programmer to make
the same mistake twice in one statement? If it's done twice, it must be
intentional?

On the other hand:

bool x = false ;
bool y = true ;

if ( x = y )
{
printf ( "\n%.*s" , x?"TRUE":"FALSE" ) ;
}

should probably not produce the error:
t.d(29): '=' does not give a boolean result


The Pascal := would be a workable alternative, but I like the less-typing =
<g>.

<soapbox> My feeling about C and UNIX is that they were created by lazy-ass idiots who felt that saving keystrokes was the be-all and end-all of programming efficiency. Instead we get problems like this which, as far I know, never occurred in earlier languages and _cause_ so much additional time and effort in debugging. </soapbox> John Boucher The King had Humpty pushed.
Sep 13 2003
next sibling parent Derek Parnell <Derek.Parnell No.Spam> writes:
On Sun, 14 Sep 2003 06:21:02 +0000 (UTC) (09/14/03 16:21:02)
, John Boucher <John_member pathlink.com> wrote:

[snip]

 <soapbox>
 My feeling about C and UNIX is that they were created by lazy-ass idiots 
 who
 felt that saving keystrokes was the be-all and end-all of programming
 efficiency. Instead we get problems like this which, as far I know, never
 occurred in earlier languages and _cause_ so much additional time and 
 effort in
 debugging.
 </soapbox>

I'm with you, John. -- Derek
Sep 14 2003
prev sibling next sibling parent "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"John Boucher" <John_member pathlink.com> ha scritto nel messaggio
news:bk11ce$epb$1 digitaldaemon.com...
 <soapbox>
 My feeling about C and UNIX is that they were created by lazy-ass idiots

 felt that saving keystrokes was the be-all and end-all of programming
 efficiency. Instead we get problems like this which, as far I know, never
 occurred in earlier languages and _cause_ so much additional time and

 debugging.
 </soapbox>

Our luck is that they used US keyboards and ASCII codes. Had Unicode been invented before K&R started working on C, there would be single Kanji characters instead of keywords... :-) Ric
Sep 15 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"John Boucher" <John_member pathlink.com> wrote in message
news:bk11ce$epb$1 digitaldaemon.com...
 I just found that the following works too, but it's still ugly:

 int x = 0 ;
 int y = 1 ;

 if ( x = y , x )
 {
 printf ( "\n%d" , x ) ;
 }

You're right, that should work.
 And take a look at:

 int x = 0 ;
 int y = 1 ;
 int z = 0 ;

 if ( x = y , z = y )
 {
 printf ( "\n%d" , x ) ;
 printf ( "\n%d" , z ) ;
 }

 which succeeds as well.

That one should issue an error, I'll fix it.
Sep 16 2003
prev sibling parent reply Derek Parnell <Derek.Parnell No.Spam> writes:
On Fri, 12 Sep 2003 18:40:56 +1000 (09/12/03 18:40:56)
, Matthew Wilson <matthew stlsoft.org> wrote:

 Touche!

 I want to echo, and maybe amplify, John Boucher, and resurrect my request
 that all conditional expressions and sub-expressions must be explicitly
 boolean. i.e. the following would not compile:

   int i;
   long j;

   if( !i || j) // Filthy stuff!

 and would have to be formed as

   if (i == 0 || j != 0)

 I know this is less likely to get in than I am to get an award for
 prosyletisation of C++'s iostreams, but what the hell! I'm someone that
 writes code with the intention that it will live a long time, so I'm far
 more interested in maintainability than in easy of first writing. It 
 never
 ceases to surprise me what little (overt at least) import this gets 
 around
 here. Sob sob. (Actually, to be fair, there seems to be precious little
 interest in maintainability in any other newsgroups that I can see, so 
 maybe
 I need to take my little friend back indoors where its warm.)

This has been my position for many years too. 100% support for this concept. 'Maintainability' and 'Legibility' have higher priority than 'less typing' and they are not always synonomous. Things ought to be as simple as possible, but not too simple. Thus greater priority should be bestowed on explicit coding rather than implicit because it tells the reader/maintainer more. Consider that one must 'translate' or 'interpret' the phrase " if not X " into " if X is 0 " and " if X " into " if X is not 0 ". This involves a slight mental flipping, and even if you can do that very quickly, it still must be done. -- Derek
Sep 14 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 I want to echo, and maybe amplify, John Boucher, and resurrect my


 that all conditional expressions and sub-expressions must be explicitly
 boolean. i.e. the following would not compile:

   int i;
   long j;

   if( !i || j) // Filthy stuff!

 and would have to be formed as

   if (i == 0 || j != 0)

 I know this is less likely to get in than I am to get an award for
 prosyletisation of C++'s iostreams, but what the hell! I'm someone that
 writes code with the intention that it will live a long time, so I'm far
 more interested in maintainability than in easy of first writing. It
 never
 ceases to surprise me what little (overt at least) import this gets
 around
 here. Sob sob. (Actually, to be fair, there seems to be precious little
 interest in maintainability in any other newsgroups that I can see, so
 maybe
 I need to take my little friend back indoors where its warm.)

This has been my position for many years too. 100% support for this concept. 'Maintainability' and 'Legibility' have higher priority than 'less typing' and they are not always synonomous.

Seems so hard to make people really believe this. Kind of like the argument that you'll live longer (and happier) if you drive slower on any journey involving traffic lights! To be aggressive/bold/assertive/grand, I will personally be very disappointed if D is not *significantly* more maintainable than C and C++. Nothing I've seen so far will make it more than *marginally* more maintainable. :( There seems to be a confusion (in the wide world, so perhaps it's just me) that programming for maintainability constrains one into producing boring/safe/nannied code. I for one am glad that D has pointers, so I can get down and dirty when I need to. But I am not happy that I can write if(x) where x can be any non-boolean type. Many a conversation I've had with people confuses these two types of things. One is power, which we need, the other sloppiness, which we neither need nor (should) want. I'm keeping my mind open and my fingers crossed. :)
 Things ought to be as simple as possible, but not too simple. Thus greater
 priority should be bestowed on explicit coding rather than implicit
 because it tells the reader/maintainer more.

I think a rather famous German scientist once said that. One must heartily concur.
 Consider that one must 'translate' or 'interpret'  the phrase  " if not X
 " into " if X is 0 " and " if X " into " if X is not 0 ". This involves a
 slight mental flipping, and even if you can do that very quickly, it still
 must be done.

Indeed. I just thought through what you said, and it's quite true. Interesting.
Sep 14 2003
next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
I hate to say it fellows but there are much much bigger fish to fry than
this, if you really want to improve maintainability.  Anything that makes
the code easier to refactor, less tightly coupled, will pay off way more
than stripping the essence of C out of the language.

If you really hate C that much, use Java or Modula3.  I for one read C++
every day.  Little crap like this doesn't even begin to faze me;  I think in
C++ terms, so if (i || !j) isn't going to bother me.  Trust me, I've seen
FAR worse than that.  And I also think that maintenance programmers, if they
can't figure out what the code is doing, they shouldn't be working on that
part of the code.  Hire someone who can handle the job.

"Save us from ourselves" is something I hear far too often...

Sean

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bk34is$6j0$1 digitaldaemon.com...
 I want to echo, and maybe amplify, John Boucher, and resurrect my


 that all conditional expressions and sub-expressions must be



 boolean. i.e. the following would not compile:

   int i;
   long j;

   if( !i || j) // Filthy stuff!

 and would have to be formed as

   if (i == 0 || j != 0)

 I know this is less likely to get in than I am to get an award for
 prosyletisation of C++'s iostreams, but what the hell! I'm someone



 writes code with the intention that it will live a long time, so I'm



 more interested in maintainability than in easy of first writing. It
 never
 ceases to surprise me what little (overt at least) import this gets
 around
 here. Sob sob. (Actually, to be fair, there seems to be precious



 interest in maintainability in any other newsgroups that I can see, so
 maybe
 I need to take my little friend back indoors where its warm.)

This has been my position for many years too. 100% support for this concept. 'Maintainability' and 'Legibility' have higher priority than 'less


 and they are not always synonomous.

Seems so hard to make people really believe this. Kind of like the

 that you'll live longer (and happier) if you drive slower on any journey
 involving traffic lights!

 To be aggressive/bold/assertive/grand, I will personally be very
 disappointed if D is not *significantly* more maintainable than C and C++.
 Nothing I've seen so far will make it more than *marginally* more
 maintainable. :(

 There seems to be a confusion (in the wide world, so perhaps it's just me)
 that programming for maintainability constrains one into producing
 boring/safe/nannied code. I for one am glad that D has pointers, so I can
 get down and dirty when I need to. But I am not happy that I can write

 where x can be any non-boolean type. Many a conversation I've had with
 people confuses these two types of things. One is power, which we need,

 other sloppiness, which we neither need nor (should) want.

 I'm keeping my mind open and my fingers crossed. :)

 Things ought to be as simple as possible, but not too simple. Thus


 priority should be bestowed on explicit coding rather than implicit
 because it tells the reader/maintainer more.

I think a rather famous German scientist once said that. One must heartily concur.
 Consider that one must 'translate' or 'interpret'  the phrase  " if not


 " into " if X is 0 " and " if X " into " if X is not 0 ". This involves


 slight mental flipping, and even if you can do that very quickly, it


 must be done.

Indeed. I just thought through what you said, and it's quite true. Interesting.

Sep 15 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
He he. There's something in what you say, Eagle-eye

"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bk3pvm$15lg$1 digitaldaemon.com...
 I hate to say it fellows but there are much much bigger fish to fry than
 this, if you really want to improve maintainability.  Anything that makes
 the code easier to refactor, less tightly coupled, will pay off way more
 than stripping the essence of C out of the language.

 If you really hate C that much, use Java or Modula3.  I for one read C++
 every day.  Little crap like this doesn't even begin to faze me;  I think

 C++ terms, so if (i || !j) isn't going to bother me.  Trust me, I've seen
 FAR worse than that.  And I also think that maintenance programmers, if

 can't figure out what the code is doing, they shouldn't be working on that
 part of the code.  Hire someone who can handle the job.

 "Save us from ourselves" is something I hear far too often...

 Sean

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bk34is$6j0$1 digitaldaemon.com...
 I want to echo, and maybe amplify, John Boucher, and resurrect my


 that all conditional expressions and sub-expressions must be



 boolean. i.e. the following would not compile:

   int i;
   long j;

   if( !i || j) // Filthy stuff!

 and would have to be formed as

   if (i == 0 || j != 0)

 I know this is less likely to get in than I am to get an award for
 prosyletisation of C++'s iostreams, but what the hell! I'm someone



 writes code with the intention that it will live a long time, so I'm



 more interested in maintainability than in easy of first writing. It
 never
 ceases to surprise me what little (overt at least) import this gets
 around
 here. Sob sob. (Actually, to be fair, there seems to be precious



 interest in maintainability in any other newsgroups that I can see,




 maybe
 I need to take my little friend back indoors where its warm.)

This has been my position for many years too. 100% support for this concept. 'Maintainability' and 'Legibility' have higher priority than 'less


 and they are not always synonomous.

Seems so hard to make people really believe this. Kind of like the

 that you'll live longer (and happier) if you drive slower on any journey
 involving traffic lights!

 To be aggressive/bold/assertive/grand, I will personally be very
 disappointed if D is not *significantly* more maintainable than C and


 Nothing I've seen so far will make it more than *marginally* more
 maintainable. :(

 There seems to be a confusion (in the wide world, so perhaps it's just


 that programming for maintainability constrains one into producing
 boring/safe/nannied code. I for one am glad that D has pointers, so I


 get down and dirty when I need to. But I am not happy that I can write

 where x can be any non-boolean type. Many a conversation I've had with
 people confuses these two types of things. One is power, which we need,

 other sloppiness, which we neither need nor (should) want.

 I'm keeping my mind open and my fingers crossed. :)

 Things ought to be as simple as possible, but not too simple. Thus


 priority should be bestowed on explicit coding rather than implicit
 because it tells the reader/maintainer more.

I think a rather famous German scientist once said that. One must


 concur.

 Consider that one must 'translate' or 'interpret'  the phrase  " if



 X
 " into " if X is 0 " and " if X " into " if X is not 0 ". This



 a
 slight mental flipping, and even if you can do that very quickly, it


 must be done.

Indeed. I just thought through what you said, and it's quite true. Interesting.


Sep 15 2003
prev sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
Matthew Wilson wrote:

Things ought to be as simple as possible, but not too simple. Thus grea=


priority should be bestowed on explicit coding rather than implicit
because it tells the reader/maintainer more.

I think a rather famous German scientist once said that. One must heart=

 concur.

This citation is spoiled. He said "So einfach wie m=F6glich =96 aber nich= t=20 einfacher" which means, literally "As simple as possible, but not=20 simpler". It was Albert Einstein. -eye
Nov 03 2003
prev sibling parent reply Mike Wynn <mike l8night.co.uk> writes:
Walter wrote:
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bjr35f$1bsg$1 digitaldaemon.com...
 
As for operator precedence, I don't even know them, because I always use
braces.

I.e. you can't remember it either and so look both ways before stepping into the street <g>. Q.E.D.

if you believe that brackets should be used to define the eval order why not use prefix notation for expression its unabigious, and you can "sum" (+ a b c) if (== a null ) { } if (&& (== b 0) (|| (!= c 1) (!= d 0) (== e 4))) { (= c (+ a b (* d c))) }
Sep 12 2003
parent Derek Parnell <Derek.Parnell No.Spam> writes:
On Fri, 12 Sep 2003 18:45:23 +0100 (09/13/03 03:45:23)
, Mike Wynn <mike l8night.co.uk> wrote:

 Walter wrote:
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bjr35f$1bsg$1 digitaldaemon.com...

 As for operator precedence, I don't even know them, because I always 
 use
 braces.

I.e. you can't remember it either and so look both ways before stepping into the street <g>. Q.E.D.

if you believe that brackets should be used to define the eval order why not use prefix notation for expression its unabigious, and you can "sum" (+ a b c) if (== a null ) { } if (&& (== b 0) (|| (!= c 1) (!= d 0) (== e 4))) { (= c (+ a b (* d c))) }

Or Forth's postfix notation... 1 c != d 0 != || e 4 == b 0 == && if c d * a b + c = then no brackets at all and still unambiguous! <G> -- Derek
Sep 14 2003