Hi all,
this is my first question to this newsgroup.
I am an experienced programmer (10+ years), and I'm
very interested in this new language.

My question is: why don't D force to use a { } block
in constructs? I mean:

if ( Expression )
  BlockStatement
[ else
  BlockStatement ]

while ( Expression )
  BlockStatement

do BlockStatement
while ( Expression )

And so on with: for, debug, version, synchronize, etc...


This has some advantages:

 - No need for an empty statement
 - No 'dangling else' parsing problem
 - No weird bugs to find, as in:

      while (i < 9)
          i++; j++;

I decided myself to always use a block in constructs 2 years
ago, and I feel very confortable with this style. I'm a full-time
C and C++ programmer, and my exeperience says that the
one-statement-only case is very rare, and even if at starts it seems
you don't need a block, frequently you add it as your code get
bigger.

I think the block is the real meaning you give to statements, as many constructs use it by default: switch, with, try, finally, ...

Ciao

I understand what you are saying about requiring braces, but IMHO not requiring braces is a good thing.  It's true that most uses will need braces anyway, but not requiring braces makes coding faster, saves lines (making the code easier to read, because you can see more of it on one screen), and just generally makes this easier to read, in my opinion.  I commonly do things such as the following:

if(...)
  foo = bar;

for(.....)
   if(condition)
   {
      ...
   }

while(isalpha(*str))
    str++;

if(....)
{
   ....
}
else if(....)
{
   ....
}
else if(....)
{
    ....
}
else
   throw Exception("Unknown condition....");

I'm just learning PERL, and have written a few scripts.  On each one, I've had at least one if() block that only had a single statement - so I omitted the braces.  Boom!  Syntax error...go back and add braces...grumble.  I'd prefer to have the flexibility.

Walter did make the rule that you could not have empty statements in if/for/while blocks.  Thus, the old C bug:

while(isalpha(*str));
    str++;

Is now a syntax error.

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

In article <3BA62A1A.C6EA2B23@deming-os.org>,
 Russ Lewis <russ@deming-os.org> writes:
|> I understand what you are saying about requiring braces, but IMHO not
|> requiring braces is a good thing.  It's true that most uses will need
|> braces anyway, but not requiring braces makes coding faster, saves lines
|> (making the code easier to read, because you can see more of it on one
|> screen), and just generally makes this easier to read, in my opinion.  I
|> commonly do things such as the following:
|>
|> if(...)
|>   foo = bar;

instead of:

if(...) {
   foo = bar;
}

It's nearly the same.

|> for(.....)
|>    if(condition)
|>    {
|>       ...
|>    }

instead of:

 for(.....) {
    if(condition)
    {
       ...
    }
 }

Here I have a point: suppose that you have 100 lines in the if body and other 100+ in the else, then it's difficult to argue that we are inside a for, looking at the center of the block.

|>
|> while(isalpha(*str))
|>     str++;

instead of:

while(isalpha(*str)) {
    str++;
}

again, you need not so much typing here.

|> if(....)
|> {
|>    ....
|> }
|> else if(....)
|> {
|>    ....
|> }
|> else if(....)
|> {
|>     ....
|> }
|> else
|>    throw Exception("Unknown condition....");

You have a point here. An exception to this rule should be
planned for else - if construct. But only one exception.

|> I'm just learning PERL, and have written a few scripts.  On each one,
|> I've had at least one if() block that only had a single statement - so I
|> omitted the braces.  Boom!  Syntax error...go back and add
|> braces...grumble.  I'd prefer to have the flexibility.

IMHO, this is not flexibility, and the time typing two more
brackets sometimes (less than 10% according to my counts) it
is not saved.
You have only to get used to it. I started two years ago, and now
I feel no problem, neither in PERL ;-)
Remeber: this way a well written C program is completely compatible
with D.

I've been first a Pascal programmer, then learnt C.
I've been used to write:

  while a > b do
     ...

when I've realized that in C I had to write:

  while (a > b)
     ...

I thought the parentesys were only useless typing (with Shift pressed, so more time consuming than the simple letters 'd' and 'o').

Now, when I return to Pascal, i tend to write:

   while (a > b) do
      ...

This way it is easier to distinguish the condition from the code. More readability means better programming.

Another thing: nowadays IDEs can auto-fill braces for you if you want.

|> Walter did make the rule that you could not have empty statements in
|> if/for/while blocks.  Thus, the old C bug:
|>
|> while(isalpha(*str));
|>     str++;
|>
|> Is now a syntax error.

Yes, but what about my example?

  while (i < 10)
       i++; j++;

and many more? I've seen plenty of them in code written
by others and by myself.
It happens mainly when adding some code later.
Sometimes with the variation:

   i = 0;
   while (i < 10)
        printf("the %dth percentage is %d\n",
               i, a[i]);
        i++;
   if (j < i)
       printf("go!"):
   else
       printf("don't go!");
       j++;

Here the indentation doesn't match with the real meaning of the code,
while a syntax error requesting a '{' would clarify, and
this is very important with primers.

Ciao

P.S.: this is only the first question, I have others: explicit
      parentesis around && within ||, as GCC says, for example.

Yes, I agree with this.  The time wasted by having to add braces would often be saved in preventing problems later.

This would make D more self-consistent, not less so, since other constructs (e.g., functions) require them.


I am surprised to find that you can omit braces from a switch (at least in gcc) if you only have one outcome:

  switch (x)
      case 4:
           printf("x is 4.\n");

Is this valid C?
And is it allowed in D?  I think it should not be...


> |> if(....)
> |> {
> |>    ....
> |> }
> |> else if(....)
> |> {
> |>    ....
> |> }
> |> else if(....)
> |> {
> |>     ....
> |> }
> |> else
> |>    throw Exception("Unknown condition....");
>
> You have a point here. An exception to this rule should be planned for else - if construct. But only one exception.

You could add a new keyword elseif or elif, so that the exception doesn't happen.  In fact, just considering "else if" to be a single keyword might also be OK.


> P.S.: this is only the first question, I have others: explicit
>      parentesis around && within ||, as GCC says, for example.

Yes, and I've been bitten by the precedences of << and | in a similar way.


It would be nice if the compiler would warn when anything happens in the code where the behaviour/interpretation isn't explicitly defined in the specification.

I had a problem in C on x86 where and int value was shifted left 32 times; you might expect that this would give zero, but the result isn't defined by C.  On Intel only the least significant 5 bits have any effect, so the value didn't change!

Roberto Mariottini wrote:

> Hi all,
> this is my first question to this newsgroup.
> I am an experienced programmer (10+ years), and I'm
> very interested in this new language.
> 
> My question is: why don't D force to use a { } block
> in constructs?

I too after some years programming decided for myself to -always- use brackets for structure and readability. Even if it requires me sometimes to hit two keys more, and spends an additional code line in some cases.

However there is a difference between a coding style and what a language enforces. It's simply if you force brackets over your users they will complain, and they will complain loudly. There's a whole kind of other programmers who usually don't maintain a 10000+ line code, but hack a 2 page code, and they will wine about every additonal key.

Almost all modern programming languages allow today free intention, and free code structure, something not beeing default some decades ago, remeber languages which required you to start your code in the 9th column, all in front was a label, and everything beyond the 50th column was a comment. Well don't know the exact numbers :o) It was a step forward to give the programmer absolute freedom how to construct his code.

However with this possiblity comes also the responsiblity himself to code in a nice style.

I think a major defect many (experimental) languages have is that the language designer tries to be smarter than the programmer, in which he fails. I personally dislike operating systems that think they are smarter than me, and know better what to do, without asking. Same goes for compilers, now even gcc 3.0 with the '-Wall -Werror' settings can nerve me, as he sometimes doesn't know what I want to do, and tries to outwit. Hoever I choose this setting myself, so this okay.

I never would code without brackets, but I don't think I should or could enforce this upon others, maybe a -force-brackets compiler switch if at all for people who choose themself to get an additonal lint on their code.

- Axel

Ben Cohen wrote:

> Yes, I agree with this.  The time wasted by having to add braces would often be saved in preventing problems later.

Maybe a compiler switch?

> This would make D more self-consistent, not less so, since other constructs (e.g., functions) require them.

Interesting argument; that does argue in favor of requiring braces.  Yet functions (and structs and classes) are a significantly different class of construct than are blocks of code.  Not hugely different, mind you, but significant nonetheless.  Hmmm.

> I am surprised to find that you can omit braces from a switch (at least in gcc) if you only have one outcome:
>
>   switch (x)
>       case 4:
>            printf("x is 4.\n");

Ack.  Even if it's legal I would agree that this is dumb coding.  Only take shortcuts that other programmers will easily recognize and understand.

> You could add a new keyword elseif or elif, so that the exception doesn't happen.  In fact, just considering "else if" to be a single keyword might also be OK.

I don't understand what you are getting at here.  Clarify, please?

In article <9o7tjr$2jgv$1@digitaldaemon.com>,
 Axel Kittenberger <axel@dtone.org> writes:
|> Roberto Mariottini wrote:
|>
|> > Hi all,
|> > this is my first question to this newsgroup.
|> > I am an experienced programmer (10+ years), and I'm
|> > very interested in this new language.
|> >
|> > My question is: why don't D force to use a { } block
|> > in constructs?
|>
|> I too after some years programming decided for myself to -always- use
|> brackets for structure and readability. Even if it requires me sometimes to
|> hit two keys more, and spends an additional code line in some cases.
|>
|> However there is a difference between a coding style and what a language
|> enforces. It's simply if you force brackets over your users they will
|> complain, and they will complain loudly. There's a whole kind of other
|> programmers who usually don't maintain a 10000+ line code, but hack a 2
|> page code, and they will wine about every additonal key.
|>
|> Almost all modern programming languages allow today free intention, and
|> free code structure, something not beeing default some decades ago, remeber
|> languages which required you to start your code in the 9th column, all in
|> front was a label, and everything beyond the 50th column was a comment.
|> Well don't know the exact numbers :o) It was a step forward to give the
|> programmer absolute freedom how to construct his code.
|>
|> However with this possiblity comes also the responsiblity himself to code
|> in a nice style.
|>
|> I think a major defect many (experimental) languages have is that the
|> language designer tries to be smarter than the programmer, in which he
|> fails. I personally dislike operating systems that think they are smarter
|> than me, and know better what to do, without asking. Same goes for
|> compilers, now even gcc 3.0 with the '-Wall -Werror' settings can nerve me,
|> as he sometimes doesn't know what I want to do, and tries to outwit. Hoever
|> I choose this setting myself, so this okay.
|>
|> I never would code without brackets, but I don't think I should or could
|> enforce this upon others, maybe a -force-brackets compiler switch if at all
|> for people who choose themself to get an additonal lint on their code.

So there is a misunderstanding. I've read in the D language specifications:

----------------------------snip---------------------------
Who D is For
Programmers who routinely use lint or similar code analysis tools to eliminate
 bugs before the code is even compiled.
People who compile with maximum warning levels turned on and who instruct
 the compiler to treat warnings as errors.
Programming managers who are forced to rely on programming style guidelines
to avoid common C bugs.
----------------------------snip---------------------------

I am one of such men.
In my opinion, a language designed for such a person should have this
feature, and many others.

Moreover, I already said that this will overcome some problems:

 - No need for an empty statement
 - No 'dangling else' parsing problem
 - No weird bugs to find, as in:

      while (i < 9)
          i++; j++;

The parser itself will be simplified, and there will be no need to be "forced to rely on programming style guidelines to avoid common bugs".

Ciao

In article <3BA78C28.AB5EAA7D@deming-os.org>, "Russ Lewis" <russ@deming-os.org> wrote:

> Ben Cohen wrote:
> 
>> Yes, I agree with this.  The time wasted by having to add braces would often be saved in preventing problems later.
> 
> Maybe a compiler switch?

This is one way out, but wouldn't it lead to more confusion?  If people find it irritating when switching between languages, they would certainly be annoyed at the difference in the same language.

>> You could add a new keyword elseif or elif, so that the exception doesn't happen.  In fact, just considering "else if" to be a single keyword might also be OK.
> 
> I don't understand what you are getting at here.  Clarify, please?

Hmm.... I think my statement was dubious and uninteresting but this is what I mean:

The language (assuming you always put in braces) has the constructs:

    if (...)
    {}

and

    if (...)
    {}
    else
    {}

Using only these, Roberto's example is either an exception or else you have to recode it in a messy way:

    if (...)
    {
        ...
    }
    else
    {
        if (...)
        {
            ...
        }
        else
        {
           /* more cases here */
        }
    }

However, if we add one of the following constructs to the language, I would say that there is no longer an exception to the rule:

    if (...)
    {}
    elif (...)
    {}
    ...
    elif (...)
    {}

or

    if (...)
    {}
    else if (...)
    {}
    ...
    else if (...)
    {}

Python uses something like the first.  The second is more like normal C.

Of course, you might think that introducing a new construct is the same as making an exception anyway, but by introducing a new construct the language spec doesn't have to say "except for else if".

Sorry if this seems silly and pointless!

In article <3BA78C28.AB5EAA7D@deming-os.org>,
 Russ Lewis <russ@deming-os.org> writes:
|> Ben Cohen wrote:
|>
|> > Yes, I agree with this.  The time wasted by having to add braces would
|> > often be saved in preventing problems later.
|>
|> Maybe a compiler switch?

See my other post.

|> > This would make D more self-consistent, not less so, since other
|> > constructs (e.g., functions) require them.
|>
|> Interesting argument; that does argue in favor of requiring braces.  Yet
|> functions (and structs and classes) are a significantly different class of
|> construct than are blocks of code.  Not hugely different, mind you, but
|> significant nonetheless.  Hmmm.

As I mentioned in my forst post, many constructs use it already
by default in the D language specification: switch, with, try, finally, ...

|> > I am surprised to find that you can omit braces from a switch (at least in
|> > gcc) if you only have one outcome:
|> >
|> >   switch (x)
|> >       case 4:
|> >            printf("x is 4.\n");
|>
|> Ack.  Even if it's legal I would agree that this is dumb coding.  Only take
|> shortcuts that other programmers will easily recognize and understand.

D already fixes this.

|> > You could add a new keyword elseif or elif, so that the exception doesn't
|> > happen.  In fact, just considering "else if" to be a single keyword might
|> > also be OK.
|>
|> I don't understand what you are getting at here.  Clarify, please?

The full quote is clear:

|> > |> if(....)
|> > |> {
|> > |>    ....
|> > |> }
|> > |> else if(....)
|> > |> {
|> > |>    ....
|> > |> }
|> > |> else if(....)
|> > |> {
|> > |>     ....
|> > |> }
|> > |> else
|> > |>    throw Exception("Unknown condition....");
|> >
|> > You have a point here. An exception to this rule should be planned for
|> > else - if construct. But only one exception.
|> You could add a new keyword elseif or elif, so that the exception doesn't
|> happen.  In fact, just considering "else if" to be a single keyword might
|> also be OK.

I think a new keyword is not needed, simply accept this common exception:

IfStatement:
  if ( Expression ) BlockStatement
  if ( Expression ) BlockStatement else BlockStatement
  if ( Expression ) BlockStatement else IfStatement

This way it is like having an else-if instruction, while not actually having it.

Ciao

In article <9o9qed$ljt$1@digitaldaemon.com>, "Roberto Mariottini" <mario@jonathan.torino.artis.it> wrote:

> So there is a misunderstanding.
> I've read in the D language specifications:
> 
> ----------------------------snip--------------------------- Who D is For
> Programmers who routinely use lint or similar code analysis tools to
> eliminate
>  bugs before the code is even compiled.
> People who compile with maximum warning levels turned on and who
> instruct
>  the compiler to treat warnings as errors.
> Programming managers who are forced to rely on programming style
> guidelines to avoid common C bugs.
> ----------------------------snip---------------------------
> 
> I am one of such men.
> In my opinion, a language designed for such a person should have this
> feature, and many others.
> 
> Moreover, I already said that this will overcome some problems:
> 
>  - No need for an empty statement
>  - No 'dangling else' parsing problem
>  - No weird bugs to find, as in:
> 
>       while (i < 9)
>           i++; j++;
> 
> The parser itself will be simplified, and there will be no need to be "forced to rely on programming style guidelines to avoid common bugs".

Yes, I agree with this.  It is also something which might be hard for lint to catch.

D already has many differences with C to make vast improvements over that language, and this would be a very minor one, which IMO actually simplifies the language.

If people are concerned with how the code looks, you could even say that braces are hard to read and that D could have block termination statements like "end if" instead.