www.digitalmars.com         C & C++   DMDScript  

D - My first question

reply mario jonathan.artis.it (Roberto Mariottini) writes:
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
Sep 17 2001
next sibling parent reply 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;

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))) ]
Sep 17 2001
parent reply mario jonathan.torino.artis.it (Roberto Mariottini) writes:
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.
Sep 18 2001
parent reply "Ben Cohen" <bc skygate.co.uk> writes:
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!
Sep 18 2001
parent reply 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?


 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?
Sep 18 2001
next sibling parent reply "Ben Cohen" <bc skygate.co.uk> writes:
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!
Sep 19 2001
parent reply Russ Lewis <russ deming-os.org> writes:
Now I get it!  I see what you mean...no 'else if' if you have to use braces.
Personally, I don't think that this is worth adding a new keyword for, and we
certainly shouldn't add special case rules (ick!).
Sep 19 2001
parent reply "Sean L. Palmer" <spalmer iname.com> writes:
When your indentation goes off the right of the screen when doing complex
if/else if/else logic, you will see the benefit of adding elseif to the
language.

There is no need for a new keyword... the parser (or in fact the lexer) can
deal with the combination "else if" as if it were a single token, elseif.

I really wouldn't mind being forced to use curly braces around all blocks
controlled by if/for/while/etc.  Keeps things consistent, and simplifies the
language spec.  But it would also mean an increased need for elseif.  I
imagine that in the future, the editor will automatically generate the
braces for you, so that when you type "if" the editor magically makes you
some blocks like so:

if [boolexpr]
[statements]

and place your cursor inside of the empty [boolexpr] block.  You type your
expression, then either type '{' or right arrow or down arrow or use the
mouse to move to the empty [statements] block.  Once you've finished typing
your statements, you either type '}' or right arrow or down arrow or use the
mouse to go to the line after the if.  The editor could also fold up (hide)
blocks for you on request so you can look at the high-level logic of a huge
multi-page function, without all the clutter, or expand each block to zoom
in on it.  A real smart editor would prevent any kind of syntax error from
ever being entered in the first place.  It could also change the language
slightly, such as removing the need for displaying or typing the parenthesis
around the boolexpr test of an if statement, and removing the need for { }
around blocks.  When saving the file it would convert blocks to { } form,
when loading a .D file it would convert { } to the IDE editor's block
format, probably parse up the whole file and keep it in memory as a graph of
some kind.

One of these days.

The thing I like about C-style { } is it's short and easy to type and if the
conscientious programmer indents them well, it makes things clear to read.
Eiffel-style "end" to delimit blocks makes sense in some ways because it
eliminates the need for the opening '{', which really seems to just be
syntactical clutter needed only to differentiate a statement from a block of
statements, and is mis-indented by many programmers which eliminates much of
the benefit of visual lining up of the indented block.  Also, if indented
properly, { } wastes two lines of valuable screen real estate which makes
some programmers turn to a style such as this to save space:

if (a > b)
{ DoSomething(); }

or

inline void Advance()
{ ++j; }

If blocks are always required, the only thing you need is the '}' or
something like 'end'.  '}' by itself sucks because it's not balanced.

I'd rather just have the editor take care of this statement grouping,
automatically providing the language's delimiters as necessary.

In fact I think this concept is worthwhile enough that I'd almost want to
separate the internal parse tree form of the language entirely from the
textual representation which gets saved to files and written in emails or
newsgroups.   Conversion between the two forms should be well-defined, of
course, but isn't it time programmers started working with code as something
besides plain text?  Just look at Visual Basic or Delphi, they already do
something like this, they could hide the text form entirely if they wanted.

Sean

"Russ Lewis" <russ deming-os.org> wrote in message
news:3BA8C300.FB9FEE09 deming-os.org...

 Now I get it!  I see what you mean...no 'else if' if you have to use


braces.

 Personally, I don't think that this is worth adding a new keyword for, and


we

 certainly shouldn't add special case rules (ick!).
Oct 28 2001
parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Your reply caused me to go back and look at my statement you were replying to.
I don't know what I was thinking.

I was insane.

I repent.

'else if' is good.

--
The Villagers are Online! 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))) ]
Oct 29 2001
prev sibling parent reply mario jonathan.torino.artis.it (Roberto Mariottini) writes:
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
Sep 19 2001
next sibling parent "Ben Cohen" <bc skygate.co.uk> writes:
In article <9o9r71$ljt$2 digitaldaemon.com>, "Roberto Mariottini"
<mario jonathan.torino.artis.it> wrote:


 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.


Yes, that's the sort of thing I mean (well, one of them).
Sep 19 2001
prev sibling parent reply Axel Kittenberger <axel dtone.org> writes:
 IfStatement:
   if ( Expression ) BlockStatement
   if ( Expression ) BlockStatement else BlockStatement
   if ( Expression ) BlockStatement else IfStatement
 


Um, where is the syntactical difference compared to the normal/standard way?

BlockStament:
  .... while ...
 |      
  .... do ...
 |      
  .... Expr ...
 |
  etc.
 |
   IfStatment
;

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


As I guess it the only think difference is that you'll get a reduce/reduce 
confilce since the after the 'else' seeing a new 'if', will not be able to 
say if it's an IfStatement from the BlockStament rule, or an IfStatement 
from your third rule.

   if ( Expression ) BlockStatement else IfStatement


- Axel
Sep 19 2001
parent reply mario jonathan.torino.artis.it (Roberto Mariottini) writes:
In article <9oa34f$qot$1 digitaldaemon.com>,
 Axel Kittenberger <axel dtone.org> writes:
|> 
|> > IfStatement:
|> >   if ( Expression ) BlockStatement
|> >   if ( Expression ) BlockStatement else BlockStatement
|> >   if ( Expression ) BlockStatement else IfStatement
|> > 
|> 
|> Um, where is the syntactical difference compared to the normal/standard way?
|> 
|> BlockStament:
|>   .... while ...
|>  |      
|>   .... do ...
|>  |      
|>   .... Expr ...
|>  |
|>   etc.
|>  |
|>    IfStatment
|> ;
|> 
|> IfStatement:
|>    if ( Expression ) BlockStatement
|>   |
|>    if ( Expression ) BlockStatement else BlockStatement
|> ;

It actually is (from the web site):

        BlockStatement:
		{ }
		{ StatementList }

	StatementList:
		Statement
		Statement StatementList
        ;

	IfStatement:
		if ( Expression ) Statement
		if ( Expression ) Statement else Statement
        ;
 
|> 
|> As I guess it the only think difference is that you'll get a reduce/reduce 
|> confilce since the after the 'else' seeing a new 'if', will not be able to 
|> say if it's an IfStatement from the BlockStament rule, or an IfStatement 
|> from your third rule.
|> >   if ( Expression ) BlockStatement else IfStatement

There is no such conflict because BlockStatement starts with the
terminal '{' and IfStatement starts with the terminal 'if'.

Ciao
Sep 19 2001
parent "Johan Bryssling" <johan.bryssling micronet.se> writes:
Hi!

Uhmm..

Time for a "funny comment"..

If you think adding two braces and using shift are "waste of time" you

probably need a typing course..

I thought you guys where joking, but I saw the point in there somewhere when

I read about the old sweet C -bug....

*big warm smile*

Have a nice day

Johan Bryssling, Software developer/Consult, Micronet

ps. IM still watching the "D" - development and still finds it interesting

so when it's ready to ship out?. =)

"Roberto Mariottini" <mario jonathan.torino.artis.it> wrote in message
news:9oahhl$136g$1 digitaldaemon.com...

 In article <9oa34f$qot$1 digitaldaemon.com>,
  Axel Kittenberger <axel dtone.org> writes:
 |>
 |> > IfStatement:
 |> >   if ( Expression ) BlockStatement
 |> >   if ( Expression ) BlockStatement else BlockStatement
 |> >   if ( Expression ) BlockStatement else IfStatement
 |> >
 |>
 |> Um, where is the syntactical difference compared to the normal/standard


way?

 |>
 |> BlockStament:
 |>   .... while ...
 |>  |
 |>   .... do ...
 |>  |
 |>   .... Expr ...
 |>  |
 |>   etc.
 |>  |
 |>    IfStatment
 |> ;
 |>
 |> IfStatement:
 |>    if ( Expression ) BlockStatement
 |>   |
 |>    if ( Expression ) BlockStatement else BlockStatement
 |> ;

 It actually is (from the web site):

         BlockStatement:
 { }
 { StatementList }

 StatementList:
 Statement
 Statement StatementList
         ;

 IfStatement:
 if ( Expression ) Statement
 if ( Expression ) Statement else Statement
         ;

 |>
 |> As I guess it the only think difference is that you'll get a


reduce/reduce

 |> confilce since the after the 'else' seeing a new 'if', will not be able


to

 |> say if it's an IfStatement from the BlockStament rule, or an


IfStatement

 |> from your third rule.
 |> >   if ( Expression ) BlockStatement else IfStatement

 There is no such conflict because BlockStatement starts with the
 terminal '{' and IfStatement starts with the terminal 'if'.

 Ciao
Sep 26 2001
prev sibling parent reply 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.

- Axel
Sep 18 2001
parent reply mario jonathan.torino.artis.it (Roberto Mariottini) writes:
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
Sep 19 2001
parent reply "Ben Cohen" <bc skygate.co.uk> writes:
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.
Sep 19 2001
parent reply Axel Kittenberger <axel dtone.org> writes:
 So there is a misunderstanding. 
 I've read in the D language specifications:


There we're also other discussions that also contraindict this mission 
statment.


 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.


End if follow this path of content of this newsgroup to the end you'll have 
re-evolution of PASCAL.

* Very very very fast compiler (~10 times faster than c)
* forces strict coding scheme to the user, 
* object pascal provides getters, setter, etc. 
* sets
* typesafe writeln() statement
etc. etc.

- Axel
Sep 19 2001
parent reply mario jonathan.torino.artis.it (Roberto Mariottini) writes:
In article <9o9v14$op5$1 digitaldaemon.com>,
 Axel Kittenberger <axel dtone.org> writes:
|> > So there is a misunderstanding. 
|> > I've read in the D language specifications:
|> 
|> There we're also other discussions that also contraindict this mission 
|> statment.

So this "mission statement" is not mandatory? Just to know.

|> > 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.
|> 
|> End if follow this path of content of this newsgroup to the end you'll have 
|> re-evolution of PASCAL.
|> 
|> * Very very very fast compiler (~10 times faster than c)

The only one fast Pascal compiler I know is the one from Borland. 
This is achieved at some costs (typically, the compiler stops at the first
error it founds). Any other Pascal compiler I know is only a little faster
than C compilers, I think because it doesn't need a pre-processor.

|> * forces strict coding scheme to the user, 

In Pascal you can easily do what I don't want to do:

 if a and b then 
    i := i + 1; j := j + 1;

It's worse even than C:

 if (a && b) 
    ++i; ++j;

Here parenthesis give more readability.
 
|> * object pascal provides getters, setter, etc. 

But Pascal doesn't. I think they are good, but this is definitely
not Pascal.

|> * sets

Good. 
Subranges also, they can improve the design-by-contract strategy.

I recognize in C++ something that I find normally in Pascal.
To me is natural: Pascal is the perfect theory, C is the weird trick.
Any language should be between those limits, IMHO. I think
theory is good only if supported by some practice, and practice is
good only if based on some theory. But this is an opinion.

Ciao
Sep 20 2001
parent "Ben Cohen" <bc skygate.co.uk> writes:
In article <9oc6aq$20n7$1 digitaldaemon.com>, "Roberto Mariottini"
<mario jonathan.torino.artis.it> wrote:


 In article <9o9v14$op5$1 digitaldaemon.com>,
  Axel Kittenberger <axel dtone.org> writes:
 |> > So there is a misunderstanding.
 |> > I've read in the D language specifications: |> |> There we're also
 other discussions that also contraindict this mission |> statment.
 
 So this "mission statement" is not mandatory? Just to know.


Hmm...   I seem to remember that the reason why C uses = for assignment
and == for comparison is that K&R decided that (since there are on average
about 4 times as many assignments as comparisons) the keystrokes saved
outweighed the problems.

But then I don't think they had such a mission statement. ;)



 |> End if follow this path of content of this newsgroup to the end
 you'll have |> re-evolution of PASCAL.

 |> * forces strict coding scheme to the user,
 
 In Pascal you can easily do what I don't want to do:
 
  if a and b then
     i := i + 1; j := j + 1;


Yes.  In ADA you have to put "end if" where the if statement ends.  This
means that it is very hard to make such mistakes.  Making braces
compulsory would be almost as good.

The ADA way is better because you can see which block is being closed (an
if or a loop, etc.) and it also lets you name the ends, as in 
"end function function_name".  

However, this is a departure from the C syntax and you'd have to change
an awful lot (e.g. structs) to keep things consistent.


The book "Code Complete" mentions that some sizeable project written in
ADA was completed basically bug free, partly because ADA has protections
such as this.
Sep 20 2001