"Pavel Minayev" <evilone@omen.ru> ha scritto nel messaggio news:acm17i$tao$1@digitaldaemon.com...
> "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:aclt0n$pm0$1@digitaldaemon.com...
>
> > I'm for this.  The IDE could auto insert braces.
>
> The Only True IDE Is Command Line! (tm)

So are you woking with a line-editor?
I love line editors, but only used with a teletype.

> I just HATE code with unnecessary braces. I understand why you want 'em. But let me write MY code in a way I want to see it.

I disagree on the term 'unnecessary'. Most modern languages have many
things that are 'unnecessary', 'features' that old languages missed.
Time tells that many things, once considered unnecessary, are required
to make the program clearer ad more robust.
BASIC considered variable declaration unnecessary. Function
prototypes were considered unnecessary by the original C authors.
C++ got rid of many things, but laks many others (that Java andD add
to it, for example).

The python language author chose to make indentation part of the
language. While some people objected (there is always some), the
vast majority of pyhton programmers adopted the new style.
What python want is something impossible with other languages:
good indentation of programs.
But in my opinion "good indentation" is not the real problem,
"good readability" is the real one.
When you get a more-than-a-million-lines-of-code C project
written by others without following a coding standard (this is not
uncommon in my experience) to work on, you'll understand that
your work would be beautiful if only you won't have to deal with
something like this:

   if (a < b)
   if (c <d)
   if (e < f)
      a = b;
   else a = c;
   else break;

   if (a<b && c()<d || e<f() && h()<g() && j<k || l()<m())
        ...

I often find bugs introduced by co-workers that misunderstood the
flow of the original code when trying to modify it. I think the company
I work for is loosing money everyday for stupid things like this.
I bet the tab-configuration of most IDE and editors is making
loose millions of dollars per year to software houses all over the
world.

I think this is _important_, not 'unnecessary'.

Ciao

"Pavel Minayev" <evilone@omen.ru> ha scritto nel messaggio news:acm1t1$tuu$1@digitaldaemon.com...
> "Roberto Mariottini" <rmariottini@lycosmail.com> wrote in message news:aclmhe$jit$1@digitaldaemon.com...
>
> > Sure, then we can apply it to functions:
> >
> > int func(int x, int y, int z) return x+2*y+3*z*x;
> > void func2(int x, int *y) *y = func(x, x+*y, x-*y);
>
> Yes, why not? It would be a useful feature for property gettors & settors:
>
>     void width(int w) width = w;
>     int width() return width;
>
> Unfortunately, it cannot be done, due to the ambiguity between forward declaration and empty statement:
>
>     void width();    // does it have a body consisting only of ;, or is it
a
> declaration?
> So we _have_ to use braces here, to disambiguate.

It's a declaration, in D you can't use ; to indicate an empty statement. So no ambiguity here, just 'inconsistenceness'.

Note that if braces were required you could use ; as an empty instruction.

> > Or to switch:
> >
> > switch(number)    case 1:    return 0;
>
> There needs to be some way for the compiler to find end of switch block. In your example, it does not know where the case ends. So, braces are required here.

Case is fall-through, so the above would be perfectly legal, as if you write:

switch (number) { case 1: } return 0;

> > Good. And what about structs:
> >
> > struct Astruct
> >    int i;
>
> Again, why not? There is no ambiguity here, so I guess the compiler could treat struct declarations that way.
>
> But even here, there's a difference. struct is a _declaration_, it's not a statement. if-else is a statement and is defined as:
>
>     if (<condition>) <statement> else <statement>
>
> Where "statement" is ANY statement. Since complex statement { } is just a way to group together simple statements, it suites as well. It has nothing to do with struct.

But has something to do with 'consistency', that we were talking of.
I propose:
    if (<expression>) <block> [else <block>]
that is consistent with:
   <type-decl> <ident> ( <arg_list>) <block>
for functions.

> > Beautiful. :-(
>
> Maybe not for you.

Definitely.

> > I vote for mandatory brackets everywhere (so the language would be
> > internally consistant).
>
> I vote for NO mandatory brackets everywhere it can be allowed (and
> maybe where it makes sence, since struct or class consisting of
> one member is not something you're gonna use more than once a year =)):
> that is, everywhere except for functions, switch, struct, class
> and enum. In other words, I vote for what is in DMD today.
>
> I don't really understand "consistency" here - why would anybody care
> why braces around struct are required, not so for if blocks...
> I care more about line count:
>
>     if (flag)
>         live();
>     else
>         die();
>
> Short AND clear, as long as you indent everything properly. Why waste 4 more lines?
>
>     if (flag)
>     {
>         live();
>     }
>     else
>     {
>         die();
>     }
>
> I don't understand... is it ANY better, clearer, easier to read than the first version?

This is the wrong example. The hello wold program is better if written in BASIC:

PRINT "Hello World!"

In D:

import something;
int main()
{
    printf("%s\n", "Hello, World!");
}

Is it ANY better, clearer, easier to read?
Look:

if (flag1)
  if (flag2)
      live();
  else
     if (flag3)
        if (flag4)
           die();
     else
        live();
else
    die();

Insert the right braces, and then tell me.

Ciao

"OddesE" <OddesE_XYZ@hotmail.com> ha scritto nel messaggio news:acqeh4$6d5$1@digitaldaemon.com...
> "Roberto Mariottini" <rmariottini@lycosmail.com> wrote in message news:aclmhe$jit$1@digitaldaemon.com...
> >
> >
> > Sure, then we can apply it to functions:
> >
> > int func(int x, int y, int z) return x+2*y+3*z*x;
> > void func2(int x, int *y) *y = func(x, x+*y, x-*y);
> >
> > Or to switch:
> >
> > switch(number)    case 1:    return 0;
> >
> > Good. And what about structs:
> >
> > struct Astruct
> >    int i;
> >
>
> Mmmm... I didn't think he meant declarations, but
> statements. struct and function declarations surely
> should have mandatory braces!

Function _declarations_ are prototypes.
Theese are function _definitions_, so instructions.

"Pavel Minayev" <evilone@omen.ru> ha scritto nel messaggio news:acqiq9$9te$1@digitaldaemon.com...
> "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:acqeh4$6d5$1@digitaldaemon.com...
>
> > Yuck!
> > Compare this:
> >
> > if (i < 0)
> > {
> >     printf ('a');
> > }
> > else if (i == 0)
> > {
> >     printf ('b');
> > }
> > else
> > {
> >     printf ('c');
> > }
>
> In fact, the right version would be even worse if brackets are mandatory:
>
>     if (i < 0)
>     {
>         printf("a");
>     }
>     else
>     {
>         if (i == 0)
>         {
>             printf("b");
>         }
>         else
>         {
>             printf("c");
>         }
>     }

In my proposal, the else-if is handled as a particular case:

  if-instr ::=  if ( <expr>) <block> |  if ( <expr>) <block> else
<else-istr>
  else-istr ::= <block> | <if-instr>

Ciao

"Roberto Mariottini" <rmariottini@lycosmail.com> wrote in message news:acvicq$1ds6$1@digitaldaemon.com...
>
> "Pavel Minayev" <evilone@omen.ru> ha scritto nel messaggio news:acm1t1$tuu$1@digitaldaemon.com...
> > "Roberto Mariottini" <rmariottini@lycosmail.com> wrote in message news:aclmhe$jit$1@digitaldaemon.com...
> >
> > > Sure, then we can apply it to functions:
> > >
> > > int func(int x, int y, int z) return x+2*y+3*z*x;
> > > void func2(int x, int *y) *y = func(x, x+*y, x-*y);
> >
> > Yes, why not? It would be a useful feature for property gettors &
settors:
> >
> >     void width(int w) width = w;
> >     int width() return width;
> >
> > Unfortunately, it cannot be done, due to the ambiguity between forward declaration and empty statement:
> >
> >     void width();    // does it have a body consisting only of ;, or is
it
> a
> > declaration?
> > So we _have_ to use braces here, to disambiguate.
>
> It's a declaration, in D you can't use ; to indicate an empty statement. So no ambiguity here, just 'inconsistenceness'.
>
> Note that if braces were required you could use ; as an empty instruction.
>
> > > Or to switch:
> > >
> > > switch(number)    case 1:    return 0;
> >
> > There needs to be some way for the compiler to find end of switch block. In your example, it does not know where the case ends. So, braces are required here.
>
> Case is fall-through, so the above would be perfectly legal, as if you write:
>
> switch (number) { case 1: } return 0;
>
> > > Good. And what about structs:
> > >
> > > struct Astruct
> > >    int i;
> >
> > Again, why not? There is no ambiguity here, so I guess the compiler
could
> > treat struct declarations that way.
> >
> > But even here, there's a difference. struct is a _declaration_, it's not a statement. if-else is a statement and is defined as:
> >
> >     if (<condition>) <statement> else <statement>
> >
> > Where "statement" is ANY statement. Since complex statement { } is just a way to group together simple statements, it suites as well. It has nothing to do with struct.
>
> But has something to do with 'consistency', that we were talking of.
> I propose:
>     if (<expression>) <block> [else <block>]
> that is consistent with:
>    <type-decl> <ident> ( <arg_list>) <block>
> for functions.
>
> > > Beautiful. :-(
> >
> > Maybe not for you.
>
> Definitely.
>
> > > I vote for mandatory brackets everywhere (so the language would be
> > > internally consistant).
> >
> > I vote for NO mandatory brackets everywhere it can be allowed (and
> > maybe where it makes sence, since struct or class consisting of
> > one member is not something you're gonna use more than once a year =)):
> > that is, everywhere except for functions, switch, struct, class
> > and enum. In other words, I vote for what is in DMD today.
> >
> > I don't really understand "consistency" here - why would anybody care
> > why braces around struct are required, not so for if blocks...
> > I care more about line count:
> >
> >     if (flag)
> >         live();
> >     else
> >         die();
> >
> > Short AND clear, as long as you indent everything properly. Why waste 4 more lines?
> >
> >     if (flag)
> >     {
> >         live();
> >     }
> >     else
> >     {
> >         die();
> >     }
> >
> > I don't understand... is it ANY better, clearer, easier to read than the first version?
>
> This is the wrong example. The hello wold program is better if written in BASIC:
>
> PRINT "Hello World!"
>
> In D:
>
> import something;
> int main()
> {
>     printf("%s\n", "Hello, World!");
> }
>
> Is it ANY better, clearer, easier to read?
> Look:
>
> if (flag1)
>   if (flag2)
>       live();
>   else
>      if (flag3)
>         if (flag4)
>            die();
>      else
>         live();
> else
>     die();

try,

    if (flag1)
    {
        if (flag2)
            live();
        else if (flag3)
           (flag4)?die():live();
    }
    else
          die();

I think it's a matter of balance to many {} make things look ugly and too little can also. Bracket compainers probably even use non-bracket syntax without even realizing it. When I program,

if (I use brackets)
{
        then I leave them in when I reduce the line count to 1
}
else
{
        unless it looks ugly
}.

Which the above does

if (I use brackets) then I leave them in when I reduce the line count to 1
else unless it looks ugly.

I like to read code my code as if was reading a well written book or text. If things are small I like to put them into one line ie

if (a == b) f(n) else g(n)

because (to me at least) they may have the potential to be converted to,

(a == b)?f(n):g(n);

Which may change into something more optimal.

The moral is don't go overboard....

(flag1)?
    (flag2)?
        live()
    :(flag3)?
        ((flag4)?die():live()):
    die():0;


> Insert the right braces, and then tell me.
>
> Ciao
>
>

Roberto Mariottini wrote:

> if (flag1)
>   if (flag2)
>       live();
>   else
>      if (flag3)
>         if (flag4)
>            die();
>      else
>         live();
> else
>     die();
> 
> Insert the right braces, and then tell me.

Nice trick screwing up the indentation - almost had me there :-)

        if( flag1 )
 {      if( flag2 )
  {     live()                  ;
  }     else
  {     if( flag3 )
   {    if( flag4 )
    {   die()                   ;
    }   else
    {   live()                  ;
   }}   else
   {    die()                   ;
 }}}

lets try a better implementation ...

1234    flags (1=true)
0xxx    nothing
100x    die()
1010    live()
1011    die()
11xx    live()

1&(2|(3&!4))    : live()
1&(!2&!(3&!4))  : die()
==1&!(2|(3&!4))
        which is a mirror of live()

hence =>

if( flag1 ) { if( flag2 || ( flag3 && !flag4() ) live(); else die(); }

        ||OR||

if( flag1 ) flag2 || ( flag3 && !flag4() ) ? live(); : die();


Which should be just as fast (due to lazy evaluation) and much clearer (or have I been doing boolean algebra for too long).

C 2002/5/28

"Roberto Mariottini" <rmariottini@lycosmail.com> wrote in message news:acvhbk$1cgn$1@digitaldaemon.com...

> > The Only True IDE Is Command Line! (tm)
>
> So are you woking with a line-editor?
> I love line editors, but only used with a teletype.

I should have said "console mode".
Yes, I type 99% of my programs in text-mode (full screen only) editors.
I use FAR + Colorer under Win32, and Midnight Commander's builtin
editor in QNX (my two development platforms).

But yes, I know how to use the good ol' EDLIN DOS command... It was pretty useful to type in BAT-files with infinite loops to drive teachers crazy, when we studied MS-DOS in school. That were great days! =)

> I disagree on the term 'unnecessary'. Most modern languages have many things that are 'unnecessary', 'features' that old languages missed. Time tells that many things, once considered unnecessary, are required to make the program clearer ad more robust.

When I say "unnecessary", I mean that code is absolutely clear, easy
to read, and will correctly compile without those braces. The definition
of "clear" and "easy to read" code is left up to the coder, in this
case it's me. =) I do insert braces sometimes even though the compiler
doesn't need them, for example, in case-blocks, and in some complex
nested if-statements. I just don't insert them _everywhere_. In my
opinion, it just makes the code more beautiful.

"anderson" <anderson@firestar.com.au> wrote in message news:acvo58$1o2a$1@digitaldaemon.com...

> I think it's a matter of balance to many {} make things look ugly and too little can also. Bracket compainers probably even use non-bracket syntax without even realizing it. When I program,

Exactly! That's what I was trying to explain for about a month already...
(or was it more?)

Nice, but I though the objective was to make things simple. But the idea is sound "get out of the square".

"C.R.Chafer" <blackmarlin@nospam.asean-mail.com> wrote in message news:acvt54$2251$1@digitaldaemon.com...
> Roberto Mariottini wrote:
>
> > if (flag1)
> >   if (flag2)
> >       live();
> >   else
> >      if (flag3)
> >         if (flag4)
> >            die();
> >      else
> >         live();
> > else
> >     die();
> >
> > Insert the right braces, and then tell me.
>
> Nice trick screwing up the indentation - almost had me there :-)
>
>         if( flag1 )
>  {      if( flag2 )
>   {     live()                  ;
>   }     else
>   {     if( flag3 )
>    {    if( flag4 )
>     {   die()                   ;
>     }   else
>     {   live()                  ;
>    }}   else
>    {    die()                   ;
>  }}}
>
> lets try a better implementation ...
>
> 1234    flags (1=true)
> 0xxx    nothing
> 100x    die()
> 1010    live()
> 1011    die()
> 11xx    live()
>
> 1&(2|(3&!4))    : live()
> 1&(!2&!(3&!4))  : die()
> ==1&!(2|(3&!4))
>         which is a mirror of live()
>
> hence =>
>
> if( flag1 ) { if( flag2 || ( flag3 && !flag4() ) live(); else die(); }
>
>         ||OR||
>
> if( flag1 ) flag2 || ( flag3 && !flag4() ) ? live(); : die();
>
>
> Which should be just as fast (due to lazy evaluation) and much clearer (or
> have I been doing boolean algebra for too long).
>
> C 2002/5/28

"Pavel Minayev" <evilone@omen.ru> wrote in message news:ad01q8$27au$1@digitaldaemon.com...
> "anderson" <anderson@firestar.com.au> wrote in message news:acvo58$1o2a$1@digitaldaemon.com...
>
> > I think it's a matter of balance to many {} make things look ugly and
too
> > little can also. Bracket compainers probably even use non-bracket syntax without even realizing it. When I program,
>
> Exactly! That's what I was trying to explain for about a month already...
> (or was it more?)


Thanks,

Sorry for changing the subject on you Pavel Minayev (it was partly Sandor
Hojtsy fault as well) but
wow, I've never had a reply this long before. And I'm kind of happy Walter
keep out of this flame war.

--
Lets shake brakes and make up.