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=


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

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

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


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

says; if a equals b then return and pass back c. Is that not correct?
   if a == b *c++;       //  aaarrrggghhh!!!

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


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


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

 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: # for int i = 1; i < something; ++i { # doStuff(); # } 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: # if (x) doThis(); # else doAnother(); Particularly if debugging output or such doesn't make any sense in there. And also like: # foreach (i, inout x; arr) x = foo(i); 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.


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.


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. 

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

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

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.

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.

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?

Dec 29 2006