www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Parenthesis

reply NN <nn-mail bk.ru> writes:
What about removing unuseful parenthesis in 'if', 'for', 'while' ?
E.g. instead of:
if(a == b)
{
  while(c)
  {
     ...
  }
}
We can write:
if a == b
{
  while c
  {
     ...
  }
}

If someone writes parenthesis the code will compile too.
So this is almost backwards compatible feature.

What about 'if' with one expression ?
Almost everyone writes curly brackets for more than one expression, so there
they will be always written, and there will be no bugs.
Dec 22 2006
next sibling parent reply Gregor Richards <Richards codu.org> writes:
NN wrote:

 What about removing unuseful parenthesis in 'if', 'for', 'while' ?
 E.g. instead of:
 if(a == b)
 {
   while(c)
   {
      ...
   }
 }
 We can write:
 if a == b
 {
   while c
   {
      ...
   }
 }


Does anybody have a spoon I can stab into my eyes? Thanks.


 
 If someone writes parenthesis the code will compile too.
 So this is almost backwards compatible feature.


And with only the price of making elegant code become inelegant, ugly 
code! Fantastic!


 
 What about 'if' with one expression ?
 Almost everyone writes curly brackets for more than one expression, so there
they will be always written, and there will be no bugs.


... what? Most people write curly brackets if they have more than one 
/statement/ (that's the word you're looking for), but with only one 
simple statement I'd say it's more like a 50-50 split.

  - Gregor Richards
Dec 22 2006
next sibling parent reply "Kristian Kilpi" <kjkilpi gmail.com> writes:
On Fri, 22 Dec 2006 19:08:31 +0200, Gregor Richards <Richards codu.org> =
 =

wrote:


 NN wrote:

 What about removing unuseful parenthesis in 'if', 'for', 'while' ?
 E.g. instead of:
 if(a =3D=3D b)
 {
   while(c)
   {
      ...
   }
 }
 We can write:
 if a =3D=3D b
 {
   while c
   {
      ...
   }
 }


 Does anybody have a spoon I can stab into my eyes? Thanks.


  If someone writes parenthesis the code will compile too.
 So this is almost backwards compatible feature.


 And with only the price of making elegant code become inelegant, ugly =


 =


 code! Fantastic!


  What about 'if' with one expression ?
 Almost everyone writes curly brackets for more than one expression, s=




o  =


 there they will be always written, and there will be no bugs.


 ... what? Most people write curly brackets if they have more than one =


 =


 /statement/ (that's the word you're looking for), but with only one  =



 simple statement I'd say it's more like a 50-50 split.

   - Gregor Richards


Well, well, it seems that Gregor is a pure C/C++/D syntax kind of a guy.=
..  =

:)

Ugliness is in the eye of the beholder, as we all know. It's a matter of=
  =

opinion. If one uses the "if a =3D=3D b" syntax a long time, (s)he will =
very  =

likely get used to it, and no longer think it's ugly.

I have programmed with C++ mainly, but "if a =3D=3D b" is not so ugly,  =

actually it's kind of okay for me (not so elegant, sure, but okay). Even=
  =

if I always write return statements insided parenthesis. Ah yes, the  =

return statements... you can write "return a" or "return(a)". So it's no=
t  =

so strange if that would apply to other statements also.

But I think that NN suggested the syntax not because it's prettier but  =

because it's easier/faster to type.

I did some testing. I use a scandinavian keyboard: 'Shift + 8' -> '(' an=
d  =

'Shift + 9' -> ')'. I wrote "if a =3D=3D 1" ten times, and then "if(a =3D=
=3D 1)"  =

(without the quotation marks):

"if a =3D=3D 1" : 21 secs.
"if(a =3D=3D 1)" : 29 secs.

(The starting and stopping of my timer took some time.) So, "if a =3D=3D=
 1" is  =

28% faster than "if(a =3D=3D 1)"...
Dec 22 2006
parent Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz asn.pl> writes:
Kristian Kilpi wrote:


 On Fri, 22 Dec 2006 19:08:31 +0200, Gregor Richards <Richards codu.org>
 wrote:
 

 NN wrote:

 What about removing unuseful parenthesis in 'if', 'for', 'while' ?






NEVA! :)


 I did some testing. I use a scandinavian keyboard: 'Shift + 8' -> '(' and
 'Shift + 9' -> ')'. I wrote "if a == 1" ten times, and then "if(a == 1)"
 (without the quotation marks):
 
 "if a == 1" : 21 secs.
 "if(a == 1)" : 29 secs.
 
 (The starting and stopping of my timer took some time.) So, "if a == 1" is
 28% faster than "if(a == 1)"...


Good code is written once and read for years.
Dec 22 2006
prev sibling next sibling parent reply Wolven <rma wolven.net> writes:
== Quote from Gregor Richards (Richards codu.org)'s article

 NN wrote:

 What about removing unuseful parenthesis in 'if', 'for', 'while' ?
 E.g. instead of:
 if(a == b)
 {
   while(c)
   {
      ...
   }
 }
 We can write:
 if a == b
 {
   while c
   {
      ...
   }
 }


 Does anybody have a spoon I can stab into my eyes? Thanks.

 If someone writes parenthesis the code will compile too.
 So this is almost backwards compatible feature.


 And with only the price of making elegant code become inelegant, ugly
 code! Fantastic!

 What about 'if' with one expression ?
 Almost everyone writes curly brackets for more than one expression, so there




they will be always written, and there will be no bugs.

 ... what? Most people write curly brackets if they have more than one
 /statement/ (that's the word you're looking for), but with only one
 simple statement I'd say it's more like a 50-50 split.
   - Gregor Richards



"Elegance" is in the eyes of the beholder...   I agree with the original poster.
All the meaningless (or not really necessary) parenthesis are, in my eyes,
hideous.  Along with the curly braces, and other C style syntax.  I'm sure
shorthand looks "elegant", to those that read and write it.  To the rest of us,
it
looks like scribbling... much like C style syntax.  Of course, I'll at least
admit
I'm biased.
Dec 22 2006
parent reply Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Fri, 22 Dec 2006 21:02:22 +0000 (UTC), Wolven <rma wolven.net>
wrote:


"Elegance" is in the eyes of the beholder...   I agree with the original poster.


I agree. Pascal-family language advocates have often ridiculed
C-family language advacates for the inelegancy of needing those
parens.

Personally, I don't much care whether block statements have mandatory
parens or not, and that shorthand-everything logic has caused
significant problems in C (though the only approach I personally
prefer to brace-based blocks are the indentation-based blocks in
Python).

But I do agree that single-statement conditionals are far from rare,
and often don't get the braces treatment, and this is also a good
thing. Redundant braces look at least as stupid as redundant parens.

You basically can't always have everything. The C and Pascal styles
for block structures have different advantages and disadvantages.
Trying to get the best of both worlds risks bringing in a whole bunch
of new problems...

  if a == b        //  fine
  {
    ...
  }

  if a == b return c;  //  errm - well...

  if a == b *c++;       //  aaarrrggghhh!!!

So, since the best-of-both-worlds doesn't work, making the brackets
optional implies making the braces non-optional. For every happy
person there's an angry person. What's the point?

Of course, we could add a Python-style colon. Pascal and Basic
advocates would generally advocate keywords in place of colons, but
they'd advocate different keywords for different block structures (if
... then, while ... do, etc etc) so a single consistent symbol sounds
good to me for reasons that have nothing to do with shorthand.

There's always an alternative syntax, in other words. But this isn't D
any more. It's a whole new language. With its own advantages and
disadvantages. I seem to recall a recurring suggestion on
comp.lang.python that the colons for block structures should be made
optional, for instance. And the indentation-haters are always
suggesting that brace-based blocks should be added.

Language designers have been messing about with block structure syntax
for decades. Innovation can still be worthwhile, but if there was a
single perfect approach that would keep everyone happy, I think
someone would have found it by now.

-- 
Remove 'wants' and 'nospam' from e-mail.
Dec 22 2006
next sibling parent reply Wolven <rma wolven.net> writes:
== Quote from Steve Horne (stephenwantshornenospam100 aol.com)'s article

 Trying to get the best of both worlds risks bringing in a whole bunch
 of new problems...
   if a == b        //  fine
   {
     ...
   }
   if a == b return c;  //  errm - well...
   if a == b *c++;       //  aaarrrggghhh!!!


Forgive me for my ignorance (I've never programmed in C), but what isn't clear
about those statements?


   if a == b return c;  //  errm - well...


This one seems perfectly clear to me.  Maybe I'm reading it wrong.  To me, it
says; if a equals b then return and pass back c.  Is that not correct?


   if a == b *c++;       //  aaarrrggghhh!!!


Likewise, this one says; if a is equal to b, add one to... pointer c?  Although
I'm not positive of the meaning of the *, everything else seems crystal clear.
Again, am I not reading it correctly?  Other than my uncertainty over the *, I
don't see any ambiguity in those statements...  or any reason why C(++)
programmers don't like them.  But since I'm not a C(++) programmer, perhaps
there's something unclear about those statements that I'm just not recognizing.

As for the a = b + c * d  statement...  The only thing I need to know is, Does
the
language use the standard arithmetic precedence?  If it does, then the statement
means a = b + (c * d)  otherwise I'd just use standard left to right
evaluation...
 i.e. a = (b + c) * d.  Other than a quick check of the language reference
(which
I SHOULD only need to do once  ) to see how it handles arithmetic precedence (or
not) where's the ambiguity?

By the way, I'm not suggesting that D should be modified to use this style of
syntax.  I understand completely that it is INTENTIONALLY "C like" to make it
easy(er) for C(++) programmers to adapt to.  So please don't take my comments as
arguing for any change.  I'm just trying to understand WHY C(++) programmers
find
statements that seem perfectly clear  to me, confusing.
Dec 23 2006
next sibling parent "Kristian Kilpi" <kjkilpi gmail.com> writes:
On Sat, 23 Dec 2006 12:44:16 +0200, Wolven <rma wolven.net> wrote:
[snip]

   if a =3D=3D b return c;  //  errm - well...


 This one seems perfectly clear to me.  Maybe I'm reading it wrong.  To=


  =


 me, it
 says; if a equals b then return and pass back c.  Is that not correct?=



It's correct.


   if a =3D=3D b *c++;       //  aaarrrggghhh!!!


 Likewise, this one says; if a is equal to b, add one to... pointer c? =


  =


 Although
 I'm not positive of the meaning of the *, everything else seems crysta=


l  =


 clear.
 Again, am I not reading it correctly?  Other than my uncertainty over =


 =


 the *, I
 don't see any ambiguity in those statements...  or any reason why C(++=


)

 programmers don't like them.  But since I'm not a C(++) programmer,  =



 perhaps
 there's something unclear about those statements that I'm just not  =



 recognizing.


The problem is how * is treaded: is it unary or binary?

I read the statement as:

if(a =3D=3D b)
     *c++;

, but using arithetic precedence it will be:

if(a =3D=3D b * c++);

Of course, in D you have to use {} to create an empty statement, so the =
 =

compiler should thread it as "if(a =3D=3D b) *c++;" too. (But that would=
 add  =

complexity to the compiler.)

Anyway, I think that *optional* parenthesis can make the code a bit hard=
er  =

to read. For example:

if(a && b) || c
     a =3D 1;

At first glance it could seem that "(a && b)" is the condition of the  =

if-statement. Of course one can write unreadable code with any given  =

syntax.
Dec 23 2006
prev sibling parent reply Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Sat, 23 Dec 2006 10:44:16 +0000 (UTC), Wolven <rma wolven.net>
wrote:


== Quote from Steve Horne (stephenwantshornenospam100 aol.com)'s article

 Trying to get the best of both worlds risks bringing in a whole bunch
 of new problems...
   if a == b        //  fine
   {
     ...
   }
   if a == b return c;  //  errm - well...
   if a == b *c++;       //  aaarrrggghhh!!!


Forgive me for my ignorance (I've never programmed in C), but what isn't clear
about those statements?


I never said they were ambiguous - I chose them to be increasingly
ugly and with increasing potential to confuse (within the limits of
short, simple examples). After all, if the meaning really is ambiguous
you just disambiguate with extra parens/braces/whatever. But we don't
all agree about what is/is not confusing.

Every programming language I have ever used has a way of explicitly
separating the conditional expression from the body statement in an if
statement. In C family languages its a closing paren. In Basic and Ada
it was the 'then' keyword. In Python it is a colon. There are
languages where a line-break is required, and so on.

The reason that every programming language has some way of explicitly
separating the conditional expression from the body statement is that
doing the separation implicitly allows too much room for confusion.



Likewise, this one says; if a is equal to b, add one to... pointer c?  Although
I'm not positive of the meaning of the *, everything else seems crystal clear.


Based on that interpretation, the pointer isn't incremented. The
variable c must be a pointer, and the value it points to is
incremented (and its pre-increment value returned, but discarded). The
prefix '*' operator dereferences a pointer in the same way that a
postfix '^' would do in Pascal. So you spotted the meaning I intended.

Now consider that the '++' operator forms an expression with a
side-effect - not a statement. It is only valid as a statement
because, in C, any expression is a valid statement. So why not
interpret it as an empty-bodied conditional with a side-effect in the
condition expression...

  if (a == (b * (c++)))  { /*  null statement  */ }

Of course this is obviously stupid to you and me - why put this
expression in an if statement. But then, the same expression rules
apply to while loops. And it is quite normal to have while loops that
have no body statements, but which exploit side-effects in the
condition expression. The compiler has to choose based on syntax rules
only, not common sense, and the choice it would make in this case is
the stupid one.

So the interpretation that you considered crystal clear (and that I
originally intended) is, when you put a bit more thought in, simply
wrong. The compiler would interpret it differently.

So tell me again how that isn't confusing...


I'm just trying to understand WHY C(++) programmers find
statements that seem perfectly clear  to me, confusing.


C-family languages already have much more potential for confusion than
Pascal-family languages. There even used to be obfuscated C contests.
No-one ever ran an obfuscated Pascal contest that I heard of. In fact,
C-family languages are infamous for being far more confusing
(potentially) than Pascal-family languages. And C-family language
programmers have embraced that and accepted it, gaining the advantages
and taking responsibility for managing the disadvantages.

C programmers simply aren't prone to whining about potential confusion
issues unless they are real.

-- 
Remove 'wants' and 'nospam' from e-mail.
Dec 23 2006
parent reply NN <nn-mail bk.ru> writes:
The reason that every programming language has some way of explicitly
separating the conditional expression from the body statement is that
doing the separation implicitly allows too much room for confusion.


IMHO if someone wants to write parenthesis, he can do it without any problems.
I see no room for confusion:

if a == b && c == d
{
 writefln("Equal");
}
else
{
 writefln("Not Equal");
}
Dec 28 2006
parent Wolven <rma wolven.net> writes:
== Quote from NN (nn-mail bk.ru)'s article

 I see no room for confusion:
 if a == b && c == d
 {
  writefln("Equal");
 }
 else
 {
  writefln("Not Equal");
 }


Exactly.  Now if you could eliminate the ugly {} and ; like...

if a == b && c == d
 writefln("Equal")
else
 writefln("Not Equal")

...you would be getting closer to nice looking, easy to read, easy to learn
syntax.  :)
Dec 28 2006
prev sibling parent NN <nn-mail bk.ru> writes:
The good point is that you can write parenthesis nevermind that you can write
without them.
If you want to write them you are wellcome:

if(a == b) { return 1; } else { return 2; }

If you don't want you can write:
if a == b { return 1; } else { return 2; }

If you allways write curly brackets you do not have a problem with
understanding the code.
Dec 23 2006
prev sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Gregor Richards wrote:

 NN wrote:

 What about removing unuseful parenthesis in 'if', 'for', 'while' ?
 E.g. instead of:
 if(a == b)
 {
   while(c)
   {
      ...
   }
 }
 We can write:
 if a == b
 {
   while c
   {
      ...
   }
 }


 
 Does anybody have a spoon I can stab into my eyes? Thanks.
 

 If someone writes parenthesis the code will compile too.
 So this is almost backwards compatible feature.


 
 And with only the price of making elegant code become inelegant, ugly 
 code! Fantastic!
 

 What about 'if' with one expression ?
 Almost everyone writes curly brackets for more than one expression, so 
 there they will be always written, and there will be no bugs.


 
 .... what? Most people write curly brackets if they have more than one 
 /statement/ (that's the word you're looking for), but with only one 
 simple statement I'd say it's more like a 50-50 split.
 
  - Gregor Richards


Personally, I almost always write in the braces.  It just makes things so much
simpler if 
I later need to go back and expand that statement body, or want to add
debugging/temporary 
output or checks of some kind.

That said, I'm not so sure D needs to drop those parentheses.  I don't even
really 
consider them superfluous.  They are encapsulating what is a special case
expression (or 
set of expressions, such as with for*each) whose meaning is dependent on the
statement at 
hand.  So:





Ew.  And before someone mentions it, yes I have worked with languages that do
things this 
way already, but most of them either have significant whitespace, significant
newlines, or 
some other such syntactic anomaly which makes this feasible.  In other cases,
it was a 
trap that had to be watched out for (expression ambiguities).  (To get around
which, guess 
what, you add parentheses.)

-- Chris Nicholson-Sauls
Dec 22 2006
parent reply Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Fri, 22 Dec 2006 15:49:22 -0600, Chris Nicholson-Sauls
<ibisbasenji gmail.com> wrote:


Personally, I almost always write in the braces.  It just makes things so much
simpler if 
I later need to go back and expand that statement body, or want to add
debugging/temporary 
output or checks of some kind.


To me, redundant braces are extra clutter, making it harder to read
the code. I used to always use them in the past, back when I was more
Pascal-family-influenced than now, but over time I just got irritated
with them. And leaving them out has never caused a problem.

The basic rule is that if I only drop the braces if the whole block
statement is on a single line - a useful way to tidy up code, and
something that can be done similarly in Pascal, but not really
Modula-2 or Ada due to begin/end issues.

Of course the amount of clutter we're talking about from braces is a
trivial issue. Just like adding in the braces when they are needed is
a trivial issue.

Not that anything above should influence anyone one way or the other.
The point is that both views are equally valid. There never will be a
definitive right way.

-- 
Remove 'wants' and 'nospam' from e-mail.
Dec 22 2006
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Steve Horne wrote:

 On Fri, 22 Dec 2006 15:49:22 -0600, Chris Nicholson-Sauls
 <ibisbasenji gmail.com> wrote:
 

 Personally, I almost always write in the braces.  It just makes things so much
simpler if 
 I later need to go back and expand that statement body, or want to add
debugging/temporary 
 output or checks of some kind.


 
 To me, redundant braces are extra clutter, making it harder to read
 the code. I used to always use them in the past, back when I was more
 Pascal-family-influenced than now, but over time I just got irritated
 with them. And leaving them out has never caused a problem.
 
 The basic rule is that if I only drop the braces if the whole block
 statement is on a single line - a useful way to tidy up code, and
 something that can be done similarly in Pascal, but not really
 Modula-2 or Ada due to begin/end issues.
 
 Of course the amount of clutter we're talking about from braces is a
 trivial issue. Just like adding in the braces when they are needed is
 a trivial issue.
 
 Not that anything above should influence anyone one way or the other.
 The point is that both views are equally valid. There never will be a
 definitive right way.
 


I can understand.  One of the few occasions where I leave them out is with
things like:



Particularly if debugging output or such doesn't make any sense in there.

And also like:


If any sensible debug output would typically come after the for*each anyway.

-- Chris Nicholson-Sauls
Dec 23 2006
prev sibling next sibling parent reply Kevin Bealer <kevinbealer gmail.com> writes:
Others have commented on aesthetics.  I think the real problem is the syntax.
Dropping the parenthesis makes it ambiguous.

if a == b * c - d;

is it:

if (a == b * c) { - d };

or

if (a == b) { * c - d };

Kevin
Dec 22 2006
next sibling parent "Kristian Kilpi" <kjkilpi gmail.com> writes:
On Sat, 23 Dec 2006 04:25:09 +0200, Kevin Bealer <kevinbealer gmail.com>=
  =

wrote:


 Others have commented on aesthetics.  I think the real problem is the =


 =


 syntax.
 Dropping the parenthesis makes it ambiguous.

 if a =3D=3D b * c - d;

 is it:

 if (a =3D=3D b * c) { - d };

 or

 if (a =3D=3D b) { * c - d };

 Kevin



So, if one chooses not to use the parenthesis, (s)he must use the braces=
.

Or, a new keyword 'then' (e.g. "if a =3D=3D b * c - d then")... Errr...


Ok, how the following is interpreted (assuming the parenthesis are  =

optional and 'then' is not used)?

if (a + 1) * c {...}

->

if((a + 1) * c) {...}

or

if(a + 1) {* c} {...}

... maybe we should stick with the original parenthesis syntax... ;)
Dec 23 2006
prev sibling parent NN <nn-mail bk.ru> writes:
You do not have an ambuity because you will allways write curly brackets:

if a == b { return 1; } else { return 2 }

This can solve the problem with forgetting the curly brackets:

if(a == b)
  writefln("a");
  return 1;

if a == b
{ // You must write this
  writefn("a");
  return 1;
} // You must write this
Dec 23 2006
prev sibling next sibling parent reply Alexander Panek <a.panek brainsware.org> writes:
I disagree.

This works well for scripting languages like Ruby, but then again, this 
is D, which has a C style syntax. And C style syntax just can't work 
without paranthesis.

Alex

NN wrote:

 What about removing unuseful parenthesis in 'if', 'for', 'while' ?
 E.g. instead of:
 if(a == b)
 {
   while(c)
   {
      ...
   }
 }
 We can write:
 if a == b
 {
   while c
   {
      ...
   }
 }
 
 If someone writes parenthesis the code will compile too.
 So this is almost backwards compatible feature.
 
 What about 'if' with one expression ?
 Almost everyone writes curly brackets for more than one expression, so there
they will be always written, and there will be no bugs.
Dec 23 2006
parent reply NN <nn-mail bk.ru> writes:
This works in some good languages, why this won't work in D ?

The good news that you still can write them ;)
If you want to write them you can, if you don't want you can too :)
Dec 23 2006
parent reply Alexander Panek <a.panek brainsware.org> writes:
NN wrote:

 This works in some good languages, why this won't work in D ?
 
 The good news that you still can write them ;)
 If you want to write them you can, if you don't want you can too :)


IMHO it offers less than the effort needed to specify (so it doesn't 
leak..) and implement it, so I don't think it's applicable.
Dec 23 2006
parent reply NN <nn-mail bk.ru> writes:
NN wrote:

 This works in some good languages, why this won't work in D ?

 The good news that you still can write them ;)
 If you want to write them you can, if you don't want you can too :)





IMHO it offers less than the effort needed to specify (so it doesn't
leak..) and implement it, so I don't think it's applicable.


It is not too much hard to implement :)
Even if it takes a week to implement, it is not too much, this will not affect
the language development too much.
Dec 23 2006
parent Alexander Panek <a.panek brainsware.org> writes:
 It is not too much hard to implement :)
 Even if it takes a week to implement, it is not too much, this will not affect
the language development too much.


There's still the leaking part.. :P
Dec 23 2006
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
NN wrote:

 What about removing unuseful parenthesis in 'if', 'for', 'while' ?


Because having redundancies in the syntax helps prevent bugs such as the 
following:


 As told by Fred Webb in alt.folklore.computers in 1990:
 
 |  I worked at Nasa during the summer of 1963.  The group I was working
 |  in was doing preliminary work on the Mission Control Center computer
 |  systems and programs.  My office mate had the job of testing out an
 |  orbit computation program which had been used during the Mercury
 |  flights.  Running some test data with known answers through it, he was
 |  getting answers that were close, but not accurate enough.  So, he
 |  started looking for numerical problems in the algorithm, checking to
 |  make sure his tests data was really correct, etc.
 |
 |  After a couple of weeks with no results, he came across a DO
 |  statement, in the form:
 |       DO 10 I=1.10
 |  This statement was interpreted by the compiler (correctly) as:
 |       DO10I = 1.10
 |  The programmer had clearly intended:
 |       DO 10 I = 1, 10
 |
 |  After changing the `.' to a `,' the program results were correct to
 |  the desired accuracy.  Apparently, the program's answers had been
 |  "good enough" for the sub-orbital Mercury flights, so no one suspected
 |  a bug until they tried to get greater accuracy, in anticipation of
 |  later orbital and moon flights.  As far as I know, this particular bug
 |  was never blamed for any actual failure of a space flight, but the
 |  other details here seem close enough that I'm sure this incident is the
 |  source of the DO story.
Dec 28 2006
next sibling parent reply Wolven <rma wolven.net> writes:
== Quote from Walter Bright (newshound digitalmars.com)'s article

 |  After a couple of weeks with no results, he came across a DO
 |  statement, in the form:
 |       DO 10 I=1.10
 |  This statement was interpreted by the compiler (correctly) as:
 |       DO10I = 1.10
 |  The programmer had clearly intended:
 |       DO 10 I = 1, 10
 |




I realize the parser ignores "whitespace", but why would it combine what are
clearly seperate tokens..  i.e. DO, 10, and I?  Seems like a logic error in the
compiler.

I can understand the I=1.10 error, depending on how I was defined.  But I would
expect that I was defined as an Integer, in which case the compiler "should"
have
given an error for trying to assign a decimal to an integer.  From my
perspective,
it sounds like they were blaming the programmer for what was really a compiler
error.  Just my opinion...  :)
Dec 28 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Wolven wrote:

 I realize the parser ignores "whitespace", but why would it combine what are
 clearly seperate tokens..  i.e. DO, 10, and I?  Seems like a logic error in the
 compiler.


That's the way FORTRAN is defined. Whitespace is ignored.
Dec 28 2006
parent reply Waldemar <waldemar wa-ba.com> writes:
== Quote from Walter Bright (newshound digitalmars.com)'s article

 Wolven wrote:

 I realize the parser ignores "whitespace", but why would it combine what are
 clearly seperate tokens..  i.e. DO, 10, and I?  Seems like a logic error in the
 compiler.


 That's the way FORTRAN is defined. Whitespace is ignored.


I thought DO10I needed to be declared as REAL.  Are you sure the problem was not
those pesky hanging chads?  Boy, those card punchers are a pain, telling you.
Which reminds me a story about a paper tape reader...

(just kidding)
Dec 28 2006
parent Walter Bright <newshound digitalmars.com> writes:
Waldemar wrote:

 == Quote from Walter Bright (newshound digitalmars.com)'s article

 Wolven wrote:

 I realize the parser ignores "whitespace", but why would it combine what are
 clearly seperate tokens..  i.e. DO, 10, and I?  Seems like a logic error in the
 compiler.


 That's the way FORTRAN is defined. Whitespace is ignored.


 
 I thought DO10I needed to be declared as REAL.


No. FORTRAN has implicit declaration.
Dec 28 2006
prev sibling parent Sean Kelly <sean f4.ca> writes:
Wolven wrote:

 == Quote from Walter Bright (newshound digitalmars.com)'s article

 |  After a couple of weeks with no results, he came across a DO
 |  statement, in the form:
 |       DO 10 I=1.10
 |  This statement was interpreted by the compiler (correctly) as:
 |       DO10I = 1.10
 |  The programmer had clearly intended:
 |       DO 10 I = 1, 10
 |




 
 I realize the parser ignores "whitespace", but why would it combine what are
 clearly seperate tokens..  i.e. DO, 10, and I?  Seems like a logic error in the
 compiler.


How does the compiler know they are separate tokens?  Remember, FORTRAN 
ignores whitespace.  In this context, the compiler doesn't know it's 
parsing a DO loop until it encounters the comma.  In other words, you 
can consider FORTRAN to be an arbitrary look-ahead language, because the 
compiler only knows how to interpret a specific statement when it 
reaches the end of the statement.  Things are even worse than they 
appear, because as far as I know, keywords in FORTRAN are not reserved.


Sean
Dec 28 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 NN wrote:

 What about removing unuseful parenthesis in 'if', 'for', 'while' ?


 
 Because having redundancies in the syntax helps prevent bugs such as the 
 following:
 

 As told by Fred Webb in alt.folklore.computers in 1990:

 |  I worked at Nasa during the summer of 1963.  The group I was working
 |  in was doing preliminary work on the Mission Control Center computer
 |  systems and programs.  My office mate had the job of testing out an
 |  orbit computation program which had been used during the Mercury
 |  flights.  Running some test data with known answers through it, he was
 |  getting answers that were close, but not accurate enough.  So, he
 |  started looking for numerical problems in the algorithm, checking to
 |  make sure his tests data was really correct, etc.
 |
 |  After a couple of weeks with no results, he came across a DO
 |  statement, in the form:
 |       DO 10 I=1.10
 |  This statement was interpreted by the compiler (correctly) as:
 |       DO10I = 1.10
 |  The programmer had clearly intended:
 |       DO 10 I = 1, 10
 |
 |  After changing the `.' to a `,' the program results were correct to
 |  the desired accuracy.  Apparently, the program's answers had been
 |  "good enough" for the sub-orbital Mercury flights, so no one suspected
 |  a bug until they tried to get greater accuracy, in anticipation of
 |  later orbital and moon flights.  As far as I know, this particular bug
 |  was never blamed for any actual failure of a space flight, but the
 |  other details here seem close enough that I'm sure this incident is 
 the
 |  source of the DO story.




Fortran is an evil, evil language.


Sean
Dec 28 2006
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Sean Kelly wrote:

 Walter Bright wrote:

 NN wrote:

 What about removing unuseful parenthesis in 'if', 'for', 'while' ?


 Because having redundancies in the syntax helps prevent bugs such as 
 the following:


 As told by Fred Webb in alt.folklore.computers in 1990:

 |  I worked at Nasa during the summer of 1963.  The group I was working
 |  in was doing preliminary work on the Mission Control Center computer
 |  systems and programs.  My office mate had the job of testing out an
 |  orbit computation program which had been used during the Mercury
 |  flights.  Running some test data with known answers through it, he 
 was
 |  getting answers that were close, but not accurate enough.  So, he
 |  started looking for numerical problems in the algorithm, checking to
 |  make sure his tests data was really correct, etc.
 |
 |  After a couple of weeks with no results, he came across a DO
 |  statement, in the form:
 |       DO 10 I=1.10
 |  This statement was interpreted by the compiler (correctly) as:
 |       DO10I = 1.10
 |  The programmer had clearly intended:
 |       DO 10 I = 1, 10
 |
 |  After changing the `.' to a `,' the program results were correct to
 |  the desired accuracy.  Apparently, the program's answers had been
 |  "good enough" for the sub-orbital Mercury flights, so no one 
 suspected
 |  a bug until they tried to get greater accuracy, in anticipation of
 |  later orbital and moon flights.  As far as I know, this particular 
 bug
 |  was never blamed for any actual failure of a space flight, but the
 |  other details here seem close enough that I'm sure this incident 
 is the
 |  source of the DO story.




 
 Fortran is an evil, evil language.
 
 
 Sean


Glad we kids nowadays never had to deal with horrors like that and COBOL. :P

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jan 01 2007
next sibling parent Georg Wrede <georg nospam.org> writes:
Bruno Medeiros wrote:

 Sean Kelly wrote:

 Fortran is an evil, evil language. 


 Glad we kids nowadays never had to deal with horrors like that and 
 COBOL. :P


Well, comes a day when "you kids" become "the old farts", and the kids 
of that day do "programming" on a virtual touch screen, manipulating 
bricks and globes, talking and humming to the computer.

Some of those kids can't even spell "since computers understand what we 
say, who needs to learn to write anyway".

And all that comes to your mind is "boy these kids have never even seen 
programming".

---

Ah well, those who haven't studied COBOL don't know of JSP and Michael 
Jackson!

And those without FORTRAN don't know Kilimanjaro.
Jan 01 2007
prev sibling parent reply %u <u digitaldaemon.com> writes:
== Quote from Bruno Medeiros (brunodomedeiros+spam com.gmail)'s
article

 Glad we kids nowadays never had to deal with horrors like that


and COBOL. :P

Simply wait until someone hunts a bug down to writing
    func(1.10)
instead of
    func(1,10)
which went undetected because func had overloads for one float
argument and two integer arguments.
Jan 01 2007
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
%u wrote:

 == Quote from Bruno Medeiros (brunodomedeiros+spam com.gmail)'s
 article

 Glad we kids nowadays never had to deal with horrors like that


 and COBOL. :P
 
 Simply wait until someone hunts a bug down to writing
     func(1.10)
 instead of
     func(1,10)
 which went undetected because func had overloads for one float
 argument and two integer arguments.
 
 


"kids" nowadays use full featured IDEs with a text hover describing the 
kind of overload while the user is typing the parameters, making it 
unlikely to make that mistake. :)


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jan 13 2007
prev sibling parent reply John Demme <me teqdruid.com> writes:
NN wrote:


 What about removing unuseful parenthesis in 'if', 'for', 'while' ?
 E.g. instead of:
 if(a == b)
 {
   while(c)
   {
      ...
   }
 }
 We can write:
 if a == b
 {
   while c
   {
      ...
   }
 }
 
 If someone writes parenthesis the code will compile too.
 So this is almost backwards compatible feature.
 
 What about 'if' with one expression ?
 Almost everyone writes curly brackets for more than one expression, so
 there they will be always written, and there will be no bugs.



I don't like this idea- parens are a good thing.  There is one paren-related
change I'd like to see, though.  I'd like to be allowed to put a '!' right
before the parens, so I could do
if !(/*some long expression*/)
        foo();
instead of
if (!(/*some long expression*/))
        foo();

The extra set of parens always bothered me.  Does this create any sort of
ambiguity?

-- 
~John Demme
me teqdruid.com
http://www.teqdruid.com/
Dec 28 2006
parent NN <nn-mail bk.ru> writes:
== Quote from John Demme (me teqdruid.com)'s article

 NN wrote:

 What about removing unuseful parenthesis in 'if', 'for', 'while' ?
 E.g. instead of:
 if(a == b)
 {
   while(c)
   {
      ...
   }
 }
 We can write:
 if a == b
 {
   while c
   {
      ...
   }
 }

 If someone writes parenthesis the code will compile too.
 So this is almost backwards compatible feature.

 What about 'if' with one expression ?
 Almost everyone writes curly brackets for more than one expression, so
 there they will be always written, and there will be no bugs.


 I don't like this idea- parens are a good thing.  There is one paren-related
 change I'd like to see, though.  I'd like to be allowed to put a '!' right
 before the parens, so I could do
 if !(/*some long expression*/)
         foo();
 instead of
 if (!(/*some long expression*/))
         foo();


And what about
if((p = f(a, b)) < 0) foo();

It can be simplified to:
if (p = f(a, b)) < 0
{
  foo();
}


 The extra set of parens always bothered me.  Does this create any sort of
 ambiguity?


Curly brackets will make no ambiguity :)
Dec 29 2006