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/

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

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

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.

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

%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