I'd like it for if() to be subject to the same treatment as while()

i.e. make the following illegal:

if (expr)
  ;
else
  ;

the valid way would be like so:

if (expr)
{}
else
{}

The language may as well be self-consistent.

Sean

> > This is already true in some cases, you can't do:
> >
> >     while (...) ;
> >
> > since that is likely a typo. Instead, use:
> >
> >     while (...) { }
> >
> > for an empty loop.

> I see a problem with the reasoning here: "I make that mistake, so I remove
it
> from the language (while {}), but I use the other feature, so I keep it
even
> if it's a common mistake for others."
>
> I personally tend to use the semi-colon 'for' and 'while' forms regularly. Typically:
>
>     for (list = first; list && !condition(list); list = list->next);

I forgot about "for".  ;)

> On the other hand, I tend to "document" that, as well as fall throughs:
>
>     for (list = first; list && !condition(list); list = list->next) /* nop
> */;
>     if (list)
>         switch (list->data)
>         {
>         case BIG:
>             list->bigflag = true;
>             /* fallthrough */
>         case SMALL:
>             ...
>         }

I also have to document my fallthroughs.  This just illustrates why it'd be safer to have to specify you *want* to fall through, instead of having to specify that you don't.

I'd much rather see the language modified like so:

switch (list->data)
{
  case BIG:
    list->bigflag = true;
    continue;  // fall through to the next case
  case SMALL:
    init();
}

I suppose an analysis on how frequently people break out of the switch at the end of the case vs how often they fall through.  Aside from Duff's device, I'd wager that breaking out is much more frequent in typical C/C++ code.

There way be some way to have either.

Sean

In article <9r3di1$9oh$1@digitaldaemon.com>, "Sean L. Palmer" <spalmer@iname.com> wrote:


>> On the other hand, I tend to "document" that, as well as fall throughs:
>>
>>     for (list = first; list && !condition(list); list = list->next) /*
>>     nop
>> */;
>>     if (list)
>>         switch (list->data)
>>         {
>>         case BIG:
>>             list->bigflag = true;
>>             /* fallthrough */
>>         case SMALL:
>>             ...
>>         }
> 
> I also have to document my fallthroughs.  This just illustrates why it'd be safer to have to specify you *want* to fall through, instead of having to specify that you don't.
> 
> I'd much rather see the language modified like so:
> 
> switch (list->data)
> {
>   case BIG:
>     list->bigflag = true;
>     continue;  // fall through to the next case
>   case SMALL:
>     init();
> }

I think you would have to keep the break, to help port existing code and to make the code clearer.  (It could be confusing otherwise.)

The other thing is that using the keyword "continue" could be a problem, since is can be used in C for a different purpose (i.e., jumping out of a containing loop), which would trip you up when porting from C to D.  (In fact the use of break but not continue in C switches is a bit asymmetric.)

> I suppose an analysis on how frequently people break out of the switch at the end of the case vs how often they fall through.  Aside from Duff's device, I'd wager that breaking out is much more frequent in typical C/C++ code.

I would agree that breaking is probably more frequent.  However, that was the reasoning by which K&R decided to use = for assignment and == for comparison (which is a frequent cause of errors) .  The way C does it makes more intuitive sense to me -- you keep going until you are told to stop.

I think it would be clearer if you have to use a keyword in both cases, so you can't accidentally omit it.

In an earlier discussion, we got rid of the break/non-break problem (sort of) by introducing a new syntax.  IMHO, the new syntax is more "C-like":

switch(list->data)
{
    case(BIG)
    {
        list->bigflag = true;
        continue case(SMALL);
           // continues into whichever case handles SMALL...even though it
turns out
           // that that case also handles MEDIUM
    };
    case(SMALL,MEDIUM)
    {
        init();
    };
    default
    {
        throw exception;
     };
};

Walter hasn't signed off on using this syntax, but I think that it really looks 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))) ]

Yes, you're right. -Walter

Sean L. Palmer wrote in message <9r3d54$9nc$1@digitaldaemon.com>...
>I'd like it for if() to be subject to the same treatment as while()
>
>i.e. make the following illegal:
>
>if (expr)
>  ;
>else
>  ;
>
>the valid way would be like so:
>
>if (expr)
>{}
>else
>{}
>
>The language may as well be self-consistent.
>
>Sean
>
>> > This is already true in some cases, you can't do:
>> >
>> >     while (...) ;
>> >
>> > since that is likely a typo. Instead, use:
>> >
>> >     while (...) { }
>> >
>> > for an empty loop.
>
>
>
>

It's definitely not C-like, totally unlike C's switch.  But I like it. Ditch the }; though.

Only problem is if the language ever allowed one to not put in a trailing semi after a statement, and didn't require a block for each case, the syntax for continue case(SMALL); might be confused with continue; case (SMALL) {}

Personally I don't like trailing semis for statement separation, but without them it's hard to tell the difference between a valid

do
{
}
while (x)

{
}

and an invalid

do
{
}

while (x)
{
}

The language itself is still well-specified, but it makes it easier for programmers to make mistakes.  However with semicolons the most common case is to forget a semicolon, so I'm kinda willing to make that trade-off.  In my script languages, I make semicolons optional.  If you want to protect yourself, use them; if you're lazy, don't.  Same thing with parenthesis around expressions in if/while statements... optional.  These are annoying because everybody on my team at work types them out different than I do.

I type like this:

while (x > 5)
{}

they type like this:

while( x > 5 )
{}

which would of course not be a problem if you could just do this:

while x > 5
{}

I can see one issue with this:

if x
  *x = 7

Does that say:  if (x) *x = 7;  or does it say:  if (x*x = 7); which is an
error?  Programmer can always put in parenthesis to clarify... no, actually
in this case they can't, because if (x) *x = 7;  could be interpreted as
this longer expression:  if ((x)*x = 7)

Problem would be solved by two things:  Disallowing assignment in if/while boolean expressions, and disallowing statements consisting of just an expression that has no side-effects.  For instance  (a>b); wouldn't be a legal statement, but assignments or function calls would be.

But oh yeah, we're talking about D here...

Sean

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3BD585B8.46597003@deming-os.org...
> In an earlier discussion, we got rid of the break/non-break problem (sort
of)
> by introducing a new syntax.  IMHO, the new syntax is more "C-like":
>
> switch(list->data)
> {
>     case(BIG)
>     {
>         list->bigflag = true;
>         continue case(SMALL);
>            // continues into whichever case handles SMALL...even though it
turns out
>            // that that case also handles MEDIUM
>     };
>     case(SMALL,MEDIUM)
>     {
>         init();
>     };
>     default
>     {
>         throw exception;
>      };
> };
>
> Walter hasn't signed off on using this syntax, but I think that it really looks good...

"Sean L. Palmer" wrote:

> It's definitely not C-like, totally unlike C's switch.  But I like it.

IMHO, C's switch is very "un-C-like."  It's the only language construct that has conceptual "blocks of code" but ditches the {}.  I would opine that this new syntax is MORE C-like than C.    :)

> Ditch the }; though.

Old habit.  Don't remember why I started doing it.    :/

--
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))) ]

In that case, would it be OK to have a perl style

	stmt if(exp);

syntax?  It's nice to not have to bog down code with structure were it's not needed.  Kind of like runtime debug output (not to be confused with compiler time debug code).

	printf("Don't make me do it! I'm warning you!\n") if(!quiet);
	do_it();
	printf("I told you I'd do it, but you didn't believe me!\n") if(debug);

To be honest, I like the perl syntax for this better anyway since it the
print that is the most important part.  In these cases that fact that
the output doesn't happen every time is kind of secondary.  The same
rarely holds for block statements.
	Anyhow, it's just a wish if you are going to take away the simple form
of if.  I'd hate to see people abuse the short circuit behavior of ||
and && to get the same brevity of expression.

Dan

Walter wrote:
> 
> Yes, you're right. -Walter
> 
> Sean L. Palmer wrote in message <9r3d54$9nc$1@digitaldaemon.com>...
> >I'd like it for if() to be subject to the same treatment as while()
> >
> >i.e. make the following illegal:
> >
> >if (expr)
> >  ;
> >else
> >  ;
> >
> >the valid way would be like so:
> >
> >if (expr)
> >{}
> >else
> >{}
> >
> >The language may as well be self-consistent.
> >
> >Sean
> >
> >> > This is already true in some cases, you can't do:
> >> >
> >> >     while (...) ;
> >> >
> >> > since that is likely a typo. Instead, use:
> >> >
> >> >     while (...) { }
> >> >
> >> > for an empty loop.
> >
> >
> >
> >

I wasn't suggesting disallowing the use of a statement instead of a block. This would still be valid in D:

if (a>b)
  CallFunction();
else
  Dont();

But this wouldn't be valid if Walter accepts my suggestion:

if (a>b)
  ;
else
  CallSomething();

But this would:

if (a>b)
{}
else
  CallSomething();

Essentially my suggestion is that the null statement should not be useable in the controlled clauses of if, while, or for statements.

I don't think I'd like perl's if syntax.  Stuff off to the right of a line of code tends to go off the side of the window, you'd have to scroll over to see it.  And this indentation wouldn't make much sense in a C-style world:

printf("Don't make me do it! I'm warning you!\n")
  if(!quiet);
do_it();
printf("I told you I'd do it, but you didn't believe me!\n")
  if(debug);

Sean

"a" <a@b.c> wrote in message news:3BD8C0C1.A2A1BC8B@b.c...
>
> In that case, would it be OK to have a perl style
>
> stmt if(exp);
>
> syntax?  It's nice to not have to bog down code with structure were it's not needed.  Kind of like runtime debug output (not to be confused with compiler time debug code).
>
> printf("Don't make me do it! I'm warning you!\n") if(!quiet);
> do_it();
> printf("I told you I'd do it, but you didn't believe me!\n") if(debug);
>
> To be honest, I like the perl syntax for this better anyway since it the
> print that is the most important part.  In these cases that fact that
> the output doesn't happen every time is kind of secondary.  The same
> rarely holds for block statements.
> Anyhow, it's just a wish if you are going to take away the simple form
> of if.  I'd hate to see people abuse the short circuit behavior of ||
> and && to get the same brevity of expression.
>
> Dan
>
> Walter wrote:
> >
> > Yes, you're right. -Walter
> >
> > Sean L. Palmer wrote in message <9r3d54$9nc$1@digitaldaemon.com>...
> > >I'd like it for if() to be subject to the same treatment as while()
> > >
> > >i.e. make the following illegal:
> > >
> > >if (expr)
> > >  ;
> > >else
> > >  ;
> > >
> > >the valid way would be like so:
> > >
> > >if (expr)
> > >{}
> > >else
> > >{}
> > >
> > >The language may as well be self-consistent.
> > >
> > >Sean
> > >
> > >> > This is already true in some cases, you can't do:
> > >> >
> > >> >     while (...) ;
> > >> >
> > >> > since that is likely a typo. Instead, use:
> > >> >
> > >> >     while (...) { }
> > >> >
> > >> > for an empty loop.
> > >
> > >
> > >
> > >

"Sean L. Palmer" wrote:
> 
> I wasn't suggesting disallowing the use of a statement instead of a block. This would still be valid in D:
[snip]
> Essentially my suggestion is that the null statement should not be useable in the controlled clauses of if, while, or for statements.

	My bad.  I mis-read.

> I don't think I'd like perl's if syntax.  Stuff off to the right of a line of code tends to go off the side of the window, you'd have to scroll over to see it.  And this indentation wouldn't make much sense in a C-style world:
> 
> printf("Don't make me do it! I'm warning you!\n")
>   if(!quiet);
> do_it();
> printf("I told you I'd do it, but you didn't believe me!\n")
>   if(debug);

	Well, I'll agree that it's a departure for C folk.  I think the above
is clear though.  I write code like that (in perl) all the time.  Using
if and unless this way make code fairly readable.  This of course
assumes you use it right.  Like any construct, it can be used to
obfuscate too.
	In any case, as long as we have the non block version of if then my
case isn't worth pursuing.

Dan