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


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

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






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.


 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






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.


 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.


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.




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


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.


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


having

 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


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.


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


way to

 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


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.


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


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






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.


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.
 


you need some order or it would all be chaos
`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.


 you need some order or it would all be chaos
 `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


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.


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


into

 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


it

 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


 it

 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


 it

 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


into

 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


maybe

 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


maybe

 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.


 "almost always" ? So then what do I do when I really _do_ want to do that


(not

 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


_no_

 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


anyway,

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

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


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>


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




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.


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




 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.


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


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




 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.


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




ter

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


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


ily

 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.
 


so why allow if( obj )
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.


 so why allow if( obj )
 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