I would like to humbly ask that semicolons not be mandatory statement separators in D, but that they be equivalent to newline, and that newline is a potential statement separator, semicolon is a definite one, and semicolon + newline is treated as only one separation.

if (ihadacoollanguage)
{
  int a = b + c
  int k = b + c +
             d + e   // these don't count because they don't parse in the
same places comma and semicolon do.
  int j = b + c
            + d + e  // it actually has to be looking for a comma or
semicolon for a newline to work instead
  // or it at least needs the remaining fragment to not to compile without
treating the eoline as a terminator
  char[]
     thisstillworkshowever(char[]a,  // comma is ok, it's just not necessary
                                      char[]b // comma optional because
there's a newline instead
                                      char[]c;  // semi optional where comma
is accepted?
                                      char[]d);
}

I mean, I would like my compiler to not pick nits about semicolons.  If I forget one, so friggin what it usually doesn't matter... the compiler has figured it out that it indeed was a missing semicolon big friggin deal, just deal with it and move on.  It should be a warning at best.  In order for the compiler to figure out that a semicolon is missing, it is known that a semicolon must be inserted to fix the problem, but since that's a legal fix it should just do it.

It's like real english, sometimes you Dot all you're P"s and q's and someTimes you don't, and yes the code would be nicer if you did all your grammar homework or weren't lazy it's not crucial to get the point across. Allowing slop in syntax allows one to do quick "phrasing" while blocking out the code and clean up the subtle issues later. (if this ever becomes an issue because maybe the program works perfectly as written)  Sometimes you just wanna test something quickly and do some cut'n'paste and the last thing you want to see is some stupid "you forgot a semicolon" problems.

Yes I realize it would maybe create a few bugs;  about as many as for(;;); has.  Number of bugs created by a construct is proportional to the number of times that construct is used by someone.  Useful constructs will inherently generate more bugs up to a point.

Sean

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:advgr5$2seb$1@digitaldaemon.com...
> I would like to humbly ask that semicolons not be mandatory statement separators in D, but that they be equivalent to newline, and that newline
is
> a potential statement separator, semicolon is a definite one, and
semicolon
> + newline is treated as only one separation.

It is a good idea, and it is implemented in Javascript. Unfortunately, it turns out to be problematic in practice. It's hard to write a grammar that accurately represents the behavior, and it can lead to troublesome error messages, etc. I worry about putting it in, and it making enhancements to the language impractical (like >> makes template argument lists a problem in C++).

Walter wrote:

> "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:advgr5$2seb$1@digitaldaemon.com...
> > I would like to humbly ask that semicolons not be mandatory statement separators in D, but that they be equivalent to newline, and that newline
> is
> > a potential statement separator, semicolon is a definite one, and
> semicolon
> > + newline is treated as only one separation.
>
> It is a good idea, and it is implemented in Javascript. Unfortunately, it turns out to be problematic in practice. It's hard to write a grammar that accurately represents the behavior, and it can lead to troublesome error messages, etc. I worry about putting it in, and it making enhancements to the language impractical (like >> makes template argument lists a problem in C++).

Agreed.

I can't come up with a good example at the moment (Sunday afternoon lethargy), but I'm certain the use of CR or LF or CRLF or LFCR or whatever as a valid statement separator would lead to problems with quoting, and would lead to a proliferation of backslashes in code and/or string constants/literals.

Or not.  I'll think about it some more when my brain turns back on tomorrow...


-BobC

"Robert W. Cunningham" <rcunning@acm.org> wrote in message news:3D03F538.B8911A2D@acm.org...
> I can't come up with a good example at the moment (Sunday afternoon
lethargy),
> but I'm certain the use of CR or LF or CRLF or LFCR or whatever as a valid statement separator would lead to problems with quoting, and would lead to
a
> proliferation of backslashes in code and/or string constants/literals.

If you have a long expression broken up across multiple lines, with the automatic ; insertion, it can produce unexpected results. The grammar being difficult to specify also makes it hard to explain, so less experienced programmers will be likely to have trouble with it. C's simple rule, put a ; at the end of each statement, is easy to get right. Sure it's redundant, but error detection and diagnosis is *entirely* dependent on redundancy in the grammar. The right amount of redundancy is not too onerous, and makes error detection and accurate error messages possible for common mistakes.

There are other examples of redundancy in D: the () in an if statement. The closing ) of a parenthesized expression. The comma between function parameters. It goes on and on...

If the compiler is smart enough to figure out there *should* be a semicolon here, why not automatically insert one?

Sean

"Walter" <walter@digitalmars.com> wrote in message news:ae14em$1cvl$1@digitaldaemon.com...
>
> "Robert W. Cunningham" <rcunning@acm.org> wrote in message news:3D03F538.B8911A2D@acm.org...
> > I can't come up with a good example at the moment (Sunday afternoon
> lethargy),
> > but I'm certain the use of CR or LF or CRLF or LFCR or whatever as a
valid
> > statement separator would lead to problems with quoting, and would lead
to
> a
> > proliferation of backslashes in code and/or string constants/literals.
>
> If you have a long expression broken up across multiple lines, with the automatic ; insertion, it can produce unexpected results. The grammar
being
> difficult to specify also makes it hard to explain, so less experienced programmers will be likely to have trouble with it. C's simple rule, put a
;
> at the end of each statement, is easy to get right. Sure it's redundant,
but
> error detection and diagnosis is *entirely* dependent on redundancy in the grammar. The right amount of redundancy is not too onerous, and makes
error
> detection and accurate error messages possible for common mistakes.
>
> There are other examples of redundancy in D: the () in an if statement.
The
> closing ) of a parenthesized expression. The comma between function parameters. It goes on and on...

I like the semicolons, I think they're pretty.

-Andy

Sean L. Palmer wrote:
> If the compiler is smart enough to figure out there *should* be a semicolon
> here, why not automatically insert one?
> 
> Sean
> 
> "Walter" <walter@digitalmars.com> wrote in message
> news:ae14em$1cvl$1@digitaldaemon.com...
> 
>>"Robert W. Cunningham" <rcunning@acm.org> wrote in message
>>news:3D03F538.B8911A2D@acm.org...
>>
>>>I can't come up with a good example at the moment (Sunday afternoon
>>
>>lethargy),
>>
>>>but I'm certain the use of CR or LF or CRLF or LFCR or whatever as a
>>
> valid
> 
>>>statement separator would lead to problems with quoting, and would lead
>>
> to
> 
>>a
>>
>>>proliferation of backslashes in code and/or string constants/literals.
>>
>>If you have a long expression broken up across multiple lines, with the
>>automatic ; insertion, it can produce unexpected results. The grammar
> 
> being
> 
>>difficult to specify also makes it hard to explain, so less experienced
>>programmers will be likely to have trouble with it. C's simple rule, put a
> 
> ;
> 
>>at the end of each statement, is easy to get right. Sure it's redundant,
> 
> but
> 
>>error detection and diagnosis is *entirely* dependent on redundancy in the
>>grammar. The right amount of redundancy is not too onerous, and makes
> 
> error
> 
>>detection and accurate error messages possible for common mistakes.
>>
>>There are other examples of redundancy in D: the () in an if statement.
> 
> The
> 
>>closing ) of a parenthesized expression. The comma between function
>>parameters. It goes on and on...
> 
> 
> 
> 

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ae2rju$9f4$1@digitaldaemon.com...
> If the compiler is smart enough to figure out there *should* be a
semicolon
> here, why not automatically insert one?

Because although that's what the error messages says, it's actually just a guess that that is what the programmer most likely intended.

Right, if you drop semicolons, then the following code is legal

    int a,b;
    int c = b+
    a = a+b

The compiler would interpret it as:
    int a,b;
    int c = b + ( a = a + b);
But probably the programmer actually just made a typo, and meant
    int a,b;
    int c = b++;
    a = a + b;



Walter wrote:

> "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ae2rju$9f4$1@digitaldaemon.com...
> > If the compiler is smart enough to figure out there *should* be a
> semicolon
> > here, why not automatically insert one?
>
> Because although that's what the error messages says, it's actually just a guess that that is what the programmer most likely intended.

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

Someone *could* write this:

int a;b,

int c = b+;
a = a ++ b;

Now what the hell does *that* do?  And how is that any more or less likely than forgetting a semicolon?

Did the programmer forget a +?  Did the programmer really mean the ++?  Or did he mean binary and unary plus?  Is the ++ postfix increment of a or prefix increment of b?

There's any number of ways to write code wrong; many of those are actually legal and compilable.

I personally don't see much benefit from mandating semicolons.

Sean


"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D0628E5.B02592D4@deming-os.org...
> Right, if you drop semicolons, then the following code is legal
>
>     int a,b;
>     int c = b+
>     a = a+b
>
> The compiler would interpret it as:
>     int a,b;
>     int c = b + ( a = a + b);
> But probably the programmer actually just made a typo, and meant
>     int a,b;
>     int c = b++;
>     a = a + b;

"Sean L. Palmer" wrote:

> Someone *could* write this:
>
> int a;b,
>
> int c = b+;
> a = a ++ b;
>
> Now what the hell does *that* do?  And how is that any more or less likely than forgetting a semicolon?

Sounds like my previous post sounded like a flame.  I'm sorry - I certainly didn't mean it that way.

What I was trying to illustrate was that a simple typo resulted in legal - but unintended code.  I thought that the example was useful because at first I was going to agree with you.  However, when the counterexample crossed my mind, I changed my opinion.  For that reason, I thought that it was a good way to illustrate my (changed) opinion.

My argument is just a variant of Walter's old argument: "If any binary stream of data is a valid code, then there are no syntax errors.  Syntax errors give you a simple sanity check to catch (some of the) invalid code."  I think that semicolons do remarkably well in that role.

Again, sorry for any flamish posts...

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