www.digitalmars.com         C & C++   DMDScript  

D - More C/C++ Features to Drop

reply "Keith Nash" <k.j.nash usa.net> writes:
Greetings,

I'm interested in the D language - here's my 2c-worth.

The website gives a list of features to drop, at
http://www.digitalmars.com/d/overview.html
and it is great that the D spec is so radical in dropping unnecessary legacy
features.  Here are my suggestions for a couple more.

1. The C syntax.
C syntax is freeform: it uses ";" to separate statements, and it uses braces
"{" and "}" to group statements together.  A good example of this is the
example D program on the web page mentioned above.

These features are unhelpful, and lead to lots of bugs.  Why?  Because,
unlike compilers, programmers aren't good at keeping track of large numbers
of "{" and "}" in deeply nested structures.  So we indent our code with
whitespace, to make it more readable.  The problem is that bugs arise when
whitespace and braces disagree, e.g. in

if (blah) {
    if (blah)
    {
        blah;
        blah;
/* This comment is not in a good place */
}
else
{
    blah;
}
blah;
blah;
/* OK, this code does
 * blah blah
 */
}

This one's easy to spot, but you might be reading code that uses an
unfamiliar convention for positioning braces.
I agree that you can run the code through an indenter, or lint, but one
stated aim of D is to remove the features of C/C++ that make it necessary to
pre-check code in this way.  Indentation will always be the most convenient
way to make structured code readable to humans: the example D program itself
demonstrates this. So why not adopt indentation as a language feature?
Perhaps the syntax should be more like Python than like C/C++.

Freeform (";").  It's bad coding practice to put more than one statement on
a line; it makes code difficult to read.  Style guidelines tell us not to do
it.  Why not design D so that style guidelines are unnecessary (this too is
one of D's stated aims) - so that it is difficult, if not impossible, to
write bad code?  Use "newline", and only "newline", as a statement
terminator.

2. Equality.
Confusion of "=" and "==" is a common source of bugs.  Please use something,
*anything*, in place of "==", even FORTRAN's ".EQ." would be better.



Whether or not you agree with these suggestions, I suggest that the language
syntax should not be exempt from examination and improvement; not least
because, after D has been released, we will no longer have the opportunity
to do this.

If you've read this far, thanks for reading.  I look forward to the day when
D replaces C/C++!

Best wishes,

Keith.
Jan 30 2002
next sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Keith Nash" <k.j.nash usa.net> wrote in message
news:a39e2f$2gk9$1 digitaldaemon.com...
 Greetings,

 I'm interested in the D language - here's my 2c-worth.

 The website gives a list of features to drop, at
 http://www.digitalmars.com/d/overview.html
 and it is great that the D spec is so radical in dropping unnecessary

 features.  Here are my suggestions for a couple more.

 1. The C syntax.
 C syntax is freeform: it uses ";" to separate statements, and it uses

 "{" and "}" to group statements together.  A good example of this is the
 example D program on the web page mentioned above.

There are a lot of Java, Perl, C, C++ programmers who are used to this. I've not done any python, but I was under the impression it relied on the indenting a real pain if your editor changes tabs to spaces, and even if 1 tab == 4 spaces not every one sets their tabstops the same.
 Freeform (";").  It's bad coding practice to put more than one statement

 a line; it makes code difficult to read.  Style guidelines tell us not to

 it.  Why not design D so that style guidelines are unnecessary (this too

 one of D's stated aims) - so that it is difficult, if not impossible, to
 write bad code?  Use "newline", and only "newline", as a statement
 terminator.

C programmers find ways round these problems, if you took away the ';' we'd use the ',' more :) consider: i = 9; a = buf[i]; b = a*i; is the almost that same as i = 9, a = buf[i], b= a*i; except that the latter will have a value of a*i. or are you intending the all statements must fit onto oneline.
 2. Equality.
 Confusion of "=" and "==" is a common source of bugs.  Please use

 *anything*, in place of "==", even FORTRAN's ".EQ." would be better.

you where to change anything. Mike.
Jan 30 2002
parent reply Ruslanas Abdrachimovas <anubis 03bar.ktu.lt> writes:
Oooo, no. That's not very good. "==" and "=" bugs are very common in
C/C++ because int<->bool types are compatible in flow control 
statements, if they weren't there were only only one possibility:
if (bool_expr1 == bool_expr2)     OR      if (bool_expr1 = bool_expr2)
{                                         {
}                                         }

Sure, it could be nice that equal and assign operators were "strict" 
different (i.e. ":=" and "==", but of course not ":=" and "=", that 
would be the same problem for some people as "=" and "==").

Ruslanas

Mike Wynn wrote:

 "Keith Nash" <k.j.nash usa.net> wrote in message
 news:a39e2f$2gk9$1 digitaldaemon.com...
 
Greetings,

I'm interested in the D language - here's my 2c-worth.

The website gives a list of features to drop, at
http://www.digitalmars.com/d/overview.html
and it is great that the D spec is so radical in dropping unnecessary

features.  Here are my suggestions for a couple more.

1. The C syntax.
C syntax is freeform: it uses ";" to separate statements, and it uses

"{" and "}" to group statements together.  A good example of this is the
example D program on the web page mentioned above.

There are a lot of Java, Perl, C, C++ programmers who are used to this. I've not done any python, but I was under the impression it relied on the indenting a real pain if your editor changes tabs to spaces, and even if 1 tab == 4 spaces not every one sets their tabstops the same.
Freeform (";").  It's bad coding practice to put more than one statement

a line; it makes code difficult to read.  Style guidelines tell us not to

it.  Why not design D so that style guidelines are unnecessary (this too

one of D's stated aims) - so that it is difficult, if not impossible, to
write bad code?  Use "newline", and only "newline", as a statement
terminator.

C programmers find ways round these problems, if you took away the ';' we'd use the ',' more :) consider: i = 9; a = buf[i]; b = a*i; is the almost that same as i = 9, a = buf[i], b= a*i; except that the latter will have a value of a*i. or are you intending the all statements must fit onto oneline.
2. Equality.
Confusion of "=" and "==" is a common source of bugs.  Please use

*anything*, in place of "==", even FORTRAN's ".EQ." would be better.

you where to change anything. Mike.

Jan 31 2002
next sibling parent reply "Sean L. Palmer" <spalmer iname.com> writes:
Actually I'm kinda partial to the way a very very old language did
assignment (the language that scripted the robots in Robot Wars on the
Apple ][, by Silas Warner if I remember correctly.  precursor to the CRobots
etc games).

It used

9 * x + 5 to a
a * speed * 3 to speed

that kind of thing.  Makes sense to read and also it's sorta easier to work
out what the machine will actually do because it reads left to right
consistently.  Parses easily for both machines and humans.  I also wouldn't
be opposed to using ->, now that that is removed from D.  Or --> or
whatever.

9 * x + 5 -> temp
temp * x - 3 -> speed

Either one definitely doesn't look like equality.  Then we could use regular
= for equality, which is also very intuitive for math folks.

Math doesn't use = as assignment, neither should programming languages.  I'm
not sure how *= , +=, etc would work in that case though...

One quirk with that language is that it didn't have unary minus (that's how
simple it was).  You had to use 0 - x.

I definitely don't like relying on indentation and newlines to delimit a
language...  but then again most of mine I just make the ; optional as most
of the time you can unambiguously tell when one expression or statement ends
and another begins (however not always, with C style grammars that allow
arbitrary expressions by themselves).

Maybe

put 9 * x + 5 in temp
put * x - 3 in speed

would clear that up cuz a statement could only be an assignment, function
call, loop, or logic, never any spurious crap like - x.  Nah, it'd never
work, I'm sure people would bitch about the extra typing.  <heh>

Sean


"Ruslanas Abdrachimovas" <anubis 03bar.ktu.lt> wrote in message
news:3C5907D3.3080507 03bar.ktu.lt...
 Oooo, no. That's not very good. "==" and "=" bugs are very common in
 C/C++ because int<->bool types are compatible in flow control
 statements, if they weren't there were only only one possibility:
 if (bool_expr1 == bool_expr2)     OR      if (bool_expr1 = bool_expr2)
 {                                         {
 }                                         }

 Sure, it could be nice that equal and assign operators were "strict"
 different (i.e. ":=" and "==", but of course not ":=" and "=", that
 would be the same problem for some people as "=" and "==").

 Ruslanas

 Mike Wynn wrote:

 "Keith Nash" <k.j.nash usa.net> wrote in message
 news:a39e2f$2gk9$1 digitaldaemon.com...

Greetings,

I'm interested in the D language - here's my 2c-worth.

The website gives a list of features to drop, at
http://www.digitalmars.com/d/overview.html
and it is great that the D spec is so radical in dropping unnecessary

features.  Here are my suggestions for a couple more.

1. The C syntax.
C syntax is freeform: it uses ";" to separate statements, and it uses

"{" and "}" to group statements together.  A good example of this is the
example D program on the web page mentioned above.

There are a lot of Java, Perl, C, C++ programmers who are used to this. I've not done any python, but I was under the impression it relied on


 indenting
 a real pain if your editor changes tabs to spaces, and even if 1 tab ==


 spaces
 not every one sets their tabstops the same.


Freeform (";").  It's bad coding practice to put more than one statement

a line; it makes code difficult to read.  Style guidelines tell us not




it.  Why not design D so that style guidelines are unnecessary (this too

one of D's stated aims) - so that it is difficult, if not impossible, to
write bad code?  Use "newline", and only "newline", as a statement
terminator.

C programmers find ways round these problems, if you took away the ';'


 use the ',' more :)

 consider:
    i = 9; a = buf[i]; b = a*i;
 is the almost that same as
   i = 9, a = buf[i], b= a*i;

 except that the latter will have a value of a*i.

 or are you intending the all statements must fit onto oneline.

2. Equality.
Confusion of "=" and "==" is a common source of bugs.  Please use

*anything*, in place of "==", even FORTRAN's ".EQ." would be better.



 you where to change anything.

 Mike.


Jan 31 2002
next sibling parent reply Ruslanas Abdrachimovas <anubis 03bar.ktu.lt> writes:
I don't like this. I think ":=" and "==" are good enough..., but 
something like this "+=" or "*=" we should leave as it is.

Ruslanas

Sean L. Palmer wrote:

 Actually I'm kinda partial to the way a very very old language did
 assignment (the language that scripted the robots in Robot Wars on the
 Apple ][, by Silas Warner if I remember correctly.  precursor to the CRobots
 etc games).
 
 It used
 
 9 * x + 5 to a
 a * speed * 3 to speed
 
 that kind of thing.  Makes sense to read and also it's sorta easier to work
 out what the machine will actually do because it reads left to right
 consistently.  Parses easily for both machines and humans.  I also wouldn't
 be opposed to using ->, now that that is removed from D.  Or --> or
 whatever.
 
 9 * x + 5 -> temp
 temp * x - 3 -> speed
 
 Either one definitely doesn't look like equality.  Then we could use regular
 = for equality, which is also very intuitive for math folks.
 
 Math doesn't use = as assignment, neither should programming languages.  I'm
 not sure how *= , +=, etc would work in that case though...
 
 One quirk with that language is that it didn't have unary minus (that's how
 simple it was).  You had to use 0 - x.
 
 I definitely don't like relying on indentation and newlines to delimit a
 language...  but then again most of mine I just make the ; optional as most
 of the time you can unambiguously tell when one expression or statement ends
 and another begins (however not always, with C style grammars that allow
 arbitrary expressions by themselves).
 
 Maybe
 
 put 9 * x + 5 in temp
 put * x - 3 in speed
 
 would clear that up cuz a statement could only be an assignment, function
 call, loop, or logic, never any spurious crap like - x.  Nah, it'd never
 work, I'm sure people would bitch about the extra typing.  <heh>
 
 Sean
 
 
 "Ruslanas Abdrachimovas" <anubis 03bar.ktu.lt> wrote in message
 news:3C5907D3.3080507 03bar.ktu.lt...
 
Oooo, no. That's not very good. "==" and "=" bugs are very common in
C/C++ because int<->bool types are compatible in flow control
statements, if they weren't there were only only one possibility:
if (bool_expr1 == bool_expr2)     OR      if (bool_expr1 = bool_expr2)
{                                         {
}                                         }

Sure, it could be nice that equal and assign operators were "strict"
different (i.e. ":=" and "==", but of course not ":=" and "=", that
would be the same problem for some people as "=" and "==").

Ruslanas

Mike Wynn wrote:


"Keith Nash" <k.j.nash usa.net> wrote in message
news:a39e2f$2gk9$1 digitaldaemon.com...


Greetings,

I'm interested in the D language - here's my 2c-worth.

The website gives a list of features to drop, at
http://www.digitalmars.com/d/overview.html
and it is great that the D spec is so radical in dropping unnecessary

features.  Here are my suggestions for a couple more.

1. The C syntax.
C syntax is freeform: it uses ";" to separate statements, and it uses

"{" and "}" to group statements together.  A good example of this is the
example D program on the web page mentioned above.

I've not done any python, but I was under the impression it relied on


indenting
a real pain if your editor changes tabs to spaces, and even if 1 tab ==


spaces
not every one sets their tabstops the same.



Freeform (";").  It's bad coding practice to put more than one statement

a line; it makes code difficult to read.  Style guidelines tell us not



do


it.  Why not design D so that style guidelines are unnecessary (this too

one of D's stated aims) - so that it is difficult, if not impossible, to
write bad code?  Use "newline", and only "newline", as a statement
terminator.



use the ',' more :)

consider:
   i = 9; a = buf[i]; b = a*i;
is the almost that same as
  i = 9, a = buf[i], b= a*i;

except that the latter will have a value of a*i.

or are you intending the all statements must fit onto oneline.


2. Equality.
Confusion of "=" and "==" is a common source of bugs.  Please use

*anything*, in place of "==", even FORTRAN's ".EQ." would be better.



you where to change anything.

Mike.



Jan 31 2002
parent "Sean L. Palmer" <spalmer iname.com> writes:
I'm not saying that D should use those syntax.  ;)  That's already pretty
much set in stone I think.

Sean


"Ruslanas Abdrachimovas" <anubis 03bar.ktu.lt> wrote in message
news:3C59367A.1070601 03bar.ktu.lt...
 I don't like this. I think ":=" and "==" are good enough..., but
 something like this "+=" or "*=" we should leave as it is.

 Ruslanas

 Sean L. Palmer wrote:

 Actually I'm kinda partial to the way a very very old language did
 assignment (the language that scripted the robots in Robot Wars on the
 Apple ][, by Silas Warner if I remember correctly.  precursor to the


 etc games).

 It used

 9 * x + 5 to a
 a * speed * 3 to speed

 that kind of thing.  Makes sense to read and also it's sorta easier to


 out what the machine will actually do because it reads left to right
 consistently.  Parses easily for both machines and humans.  I also


 be opposed to using ->, now that that is removed from D.  Or --> or
 whatever.

 9 * x + 5 -> temp
 temp * x - 3 -> speed

 Either one definitely doesn't look like equality.  Then we could use


 = for equality, which is also very intuitive for math folks.

 Math doesn't use = as assignment, neither should programming languages.


 not sure how *= , +=, etc would work in that case though...

 One quirk with that language is that it didn't have unary minus (that's


 simple it was).  You had to use 0 - x.

 I definitely don't like relying on indentation and newlines to delimit a
 language...  but then again most of mine I just make the ; optional as


 of the time you can unambiguously tell when one expression or statement


 and another begins (however not always, with C style grammars that allow
 arbitrary expressions by themselves).

 Maybe

 put 9 * x + 5 in temp
 put * x - 3 in speed

 would clear that up cuz a statement could only be an assignment,


 call, loop, or logic, never any spurious crap like - x.  Nah, it'd never
 work, I'm sure people would bitch about the extra typing.  <heh>

 Sean


 "Ruslanas Abdrachimovas" <anubis 03bar.ktu.lt> wrote in message
 news:3C5907D3.3080507 03bar.ktu.lt...

Oooo, no. That's not very good. "==" and "=" bugs are very common in
C/C++ because int<->bool types are compatible in flow control
statements, if they weren't there were only only one possibility:
if (bool_expr1 == bool_expr2)     OR      if (bool_expr1 = bool_expr2)
{                                         {
}                                         }

Sure, it could be nice that equal and assign operators were "strict"
different (i.e. ":=" and "==", but of course not ":=" and "=", that
would be the same problem for some people as "=" and "==").

Ruslanas

Mike Wynn wrote:


"Keith Nash" <k.j.nash usa.net> wrote in message
news:a39e2f$2gk9$1 digitaldaemon.com...


Greetings,

I'm interested in the D language - here's my 2c-worth.

The website gives a list of features to drop, at
http://www.digitalmars.com/d/overview.html
and it is great that the D spec is so radical in dropping unnecessary

features.  Here are my suggestions for a couple more.

1. The C syntax.
C syntax is freeform: it uses ";" to separate statements, and it uses

"{" and "}" to group statements together.  A good example of this is





example D program on the web page mentioned above.

I've not done any python, but I was under the impression it relied on


indenting
a real pain if your editor changes tabs to spaces, and even if 1 tab ==


spaces
not every one sets their tabstops the same.



Freeform (";").  It's bad coding practice to put more than one






a line; it makes code difficult to read.  Style guidelines tell us not



do


it.  Why not design D so that style guidelines are unnecessary (this






one of D's stated aims) - so that it is difficult, if not impossible,





write bad code?  Use "newline", and only "newline", as a statement
terminator.



use the ',' more :)

consider:
   i = 9; a = buf[i]; b = a*i;
is the almost that same as
  i = 9, a = buf[i], b= a*i;

except that the latter will have a value of a*i.

or are you intending the all statements must fit onto oneline.


2. Equality.
Confusion of "=" and "==" is a common source of bugs.  Please use

*anything*, in place of "==", even FORTRAN's ".EQ." would be better.



you where to change anything.

Mike.




Jan 31 2002
prev sibling next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Sean L. Palmer" <spalmer iname.com> wrote in message
news:a3b30k$2npi$1 digitaldaemon.com...

 consistently.  Parses easily for both machines and humans.  I also

 be opposed to using ->, now that that is removed from D.  Or --> or
 whatever.

 9 * x + 5 -> temp
 temp * x - 3 -> speed

Knuth fan, eh? =)
 Math doesn't use = as assignment, neither should programming languages.

 not sure how *= , +=, etc would work in that case though...

Math uses :=
Jan 31 2002
parent reply "Sean L. Palmer" <spalmer iname.com> writes:
 Math doesn't use = as assignment, neither should programming languages.

 not sure how *= , +=, etc would work in that case though...

Math uses :=

I thought Math used BASIC's "let" let x = 5 which is kind of like "enforced" equality, which I guess works similarly to assignment. Sean
Jan 31 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Sean L. Palmer" <spalmer iname.com> wrote in message
news:a3c4i8$dja$1 digitaldaemon.com...

 I thought Math used BASIC's "let"

 let x = 5

 which is kind of like "enforced" equality, which I guess works similarly

 assignment.

Mathematicians seem to dislike words, so they prefer symbols. In the literature I've read, := was used for the assignment. It's also so in MathCAD. BTW BASIC's "LET" is abandoned for ages. Not even all compilers support it - my does tho =)
Jan 31 2002
parent "Juan Carlos Arevalo Baeza" <jcab roningames.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a3c5vu$m9h$1 digitaldaemon.com...
 "Sean L. Palmer" <spalmer iname.com> wrote in message
 news:a3c4i8$dja$1 digitaldaemon.com...

 I thought Math used BASIC's "let"

 let x = 5

 which is kind of like "enforced" equality, which I guess works similarly

 assignment.

Mathematicians seem to dislike words, so they prefer symbols. In the literature I've read, := was used for the assignment. It's also so in MathCAD. BTW BASIC's "LET" is abandoned for ages. Not even all compilers support it - my does tho =)

"let" is still widely used in functional languages (Haskell, ML et al). Its meaning is NOT assignment. It is a definition of a constant value, used for convenience and to improve performance. So: let x = y+1 is equivalent to the C++: const <put type here> x = y + 1; Note that: let x = x + 1 is a bottomless recursive computation (effectively an infinite loop that eventually runs out of stack). Salutaciones, JCAB
Jan 31 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <spalmer iname.com> wrote in message
news:a3b30k$2npi$1 digitaldaemon.com...
 It used

 9 * x + 5 to a
 a * speed * 3 to speed

 that kind of thing.  Makes sense to read and also it's sorta easier to

 out what the machine will actually do because it reads left to right
 consistently.  Parses easily for both machines and humans.  I also

 be opposed to using ->, now that that is removed from D.  Or --> or
 whatever.

That will work, but it's too different from the look and feel of C.
 I definitely don't like relying on indentation and newlines to delimit a
 language...  but then again most of mine I just make the ; optional as

 of the time you can unambiguously tell when one expression or statement

 and another begins (however not always, with C style grammars that allow
 arbitrary expressions by themselves).

Javascript has optional semicolons. It sounds like a good idea, but in practice it causes a lot of subtle problems with the parser. Some level of redundancy is necessary in a useful language, because it enables the compilers to detect errors. No redundancy means that any stream of random tty noise is a valid program. Requiring semicolons in C enables more typo errors to be diagnosed at compile time rather than at debug time. Too much redundancy, however, makes a language just annoying to program in <g>.
Feb 01 2002
parent reply "D" <s_nudds hotmail.com> writes:
Semicolons aren't redundant in C/C++ whitespace and <EOL> are ignored.  As a
result semicolons are considered <EOL>.  There is no significant problems
caused by considering the real <EOL> to be equivalent to a semicolon with
the exception that you lose the ability to spread single statments over
multiple lines.  To that end, you have to define another symbol as a line
continuation symbol.  When this symbol is encountered, the next true <EOL>
is ignored.

It's as simple as that.


 Javascript has optional semicolons. It sounds like a good idea, but in
 practice it causes a lot of subtle problems with the parser. Some level of
 redundancy is necessary in a useful language, because it enables the
 compilers to detect errors. No redundancy means that any stream of random
 tty noise is a valid program. Requiring semicolons in C enables more typo
 errors to be diagnosed at compile time rather than at debug time. Too much
 redundancy, however, makes a language just annoying to program in <g>.

Feb 03 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"D" <s_nudds hotmail.com> wrote in message
news:a3lf84$pao$1 digitaldaemon.com...

 Semicolons aren't redundant in C/C++ whitespace and <EOL> are ignored.  As

 result semicolons are considered <EOL>.  There is no significant problems
 caused by considering the real <EOL> to be equivalent to a semicolon with
 the exception that you lose the ability to spread single statments over
 multiple lines.  To that end, you have to define another symbol as a line
 continuation symbol.  When this symbol is encountered, the next true <EOL>
 is ignored.

 It's as simple as that.

Not really. Some languages (Euphoria, Lua - those I know well) don't use statement delimiters at all. You can write: if a = 1 then a += 1 end -- or -- if a = 1 then a += 1 end -- or even -- if a = 1 then a += 1 end Still, I prefer to have semicolons. They make life easier when reading code, and help compiler to parse some complicated cases.
Feb 04 2002
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Isn't 'end' the statement delimiter in the examples below?

Pavel Minayev wrote:

     if a = 1 then a += 1 end

     -- or --

     if a = 1 then
         a += 1
     end

     -- or even --

     if a
     = 1 then a
     += 1 end

 Still, I prefer to have semicolons. They make life easier when reading
 code, and help compiler to parse some complicated cases.

-- 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))) ]
Feb 04 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3C5ECA86.97EDD361 deming-os.org...

 Isn't 'end' the statement delimiter in the examples below?

No, it's end of block, not end of statement. You could see something like this in Lua: function foo(a, b) a += 1 bar() if a > 10 then a = 0 end baz(a) end Just a legal piece of code =)
Feb 04 2002
parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
k, I see now :)

--
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))) ]
Feb 04 2002
prev sibling parent "Sean L. Palmer" <spalmer iname.com> writes:
Sounds like a PITA... not a good tradeoff.

Sean

"D" <s_nudds hotmail.com> wrote in message
news:a3lf84$pao$1 digitaldaemon.com...
 Semicolons aren't redundant in C/C++ whitespace and <EOL> are ignored.  As

 result semicolons are considered <EOL>.  There is no significant problems
 caused by considering the real <EOL> to be equivalent to a semicolon with
 the exception that you lose the ability to spread single statments over
 multiple lines.  To that end, you have to define another symbol as a line
 continuation symbol.  When this symbol is encountered, the next true <EOL>
 is ignored.

 It's as simple as that.


 Javascript has optional semicolons. It sounds like a good idea, but in
 practice it causes a lot of subtle problems with the parser. Some level


 redundancy is necessary in a useful language, because it enables the
 compilers to detect errors. No redundancy means that any stream of


 tty noise is a valid program. Requiring semicolons in C enables more


 errors to be diagnosed at compile time rather than at debug time. Too


 redundancy, however, makes a language just annoying to program in <g>.


Feb 04 2002
prev sibling next sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
I never sugested '=' (single equals as equality)

I guess I should have said ;
have a real boolean like Java so none of the
int a ; if ( a ) {...} and more of : int a; if ( a == 0 ) { ... }
that's equal equal like C/D/Java/etc etc
that's about 80% of the '=' "==" bugs
them replace assign ('=') with ":=" Like Pascal etc
this is inline with all the += <<= -= operators;
straight assign not operator assign
and '=' is never to be seen.
 you can't have
int a; if ( a := b ) {.. }
instead
int a; if ( (a := b) == 0 ) {.. }
I've not heard a java programmer complain about having to add 3/4 extra
symbols
as the time spent is well worth it.
and the compiled code is the same (try it with your C compiler)

Mike.

"Ruslanas Abdrachimovas" <anubis 03bar.ktu.lt> wrote in message
news:3C5907D3.3080507 03bar.ktu.lt...
 Oooo, no. That's not very good. "==" and "=" bugs are very common in
 C/C++ because int<->bool types are compatible in flow control
 statements, if they weren't there were only only one possibility:
 if (bool_expr1 == bool_expr2)     OR      if (bool_expr1 = bool_expr2)
 {                                         {
 }                                         }

 Sure, it could be nice that equal and assign operators were "strict"
 different (i.e. ":=" and "==", but of course not ":=" and "=", that
 would be the same problem for some people as "=" and "==").

 Ruslanas

 Mike Wynn wrote:




 you where to change anything.

 Mike.


Jan 31 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
D has "real" bools (bits are), it's just syntax-relaxed.
Jan 31 2002
next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
 D has "real" bools (bits are), it's just syntax-relaxed.

BTW, Walter, could you please define binary operators on bit so it doesn't get converted to byte - so that ~true is false, not 0xfe =)
Jan 31 2002
prev sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
A bit is a bit, a boolean is not (it can be reprosented as one)
but (a < 8) does not eval to a bit, it should eval to a boolean
which could be a bit or an int.

real booleans is a concept, not a physical storage, how the compiler
internally represents then is up to it, to use a bit to make a boolean a bit
would allow
bit a;
if ( a = 1 ) { ... } to pass without warning, which is not wanted
booleans have the value true or false (keywords) not numeric values
there is not conversion from int to bool but bool to int is 0 false, true 1
so the C habit of doing a =!!a;
becomes a = (a!=0);
or a= !(a==0);
that's my 10c

Mike.
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a3c21m$2hmd$1 digitaldaemon.com...
 D has "real" bools (bits are), it's just syntax-relaxed.

Jan 31 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
news:a3c6b9$n9e$1 digitaldaemon.com...

 A bit is a bit, a boolean is not (it can be reprosented as one)
 but (a < 8) does not eval to a bit, it should eval to a boolean
 which could be a bit or an int.

 real booleans is a concept, not a physical storage, how the compiler
 internally represents then is up to it, to use a bit to make a boolean a

 would allow
 bit a;
 if ( a = 1 ) { ... } to pass without warning, which is not wanted
 booleans have the value true or false (keywords) not numeric values
 there is not conversion from int to bool but bool to int is 0 false, true

 so the C habit of doing a =!!a;
 becomes a = (a!=0);
 or a= !(a==0);
 that's my 10c

I've got used to C's relaxed type-checking... but I understand the benefits of having a separate bool type. Actually, I don't mind if there is one or not.
Jan 31 2002
parent reply "D" <s_nudds hotmail.com> writes:
With respect to boolean types, it is essential that the language have
predefined constants for true and false.

 I've got used to C's relaxed type-checking... but I understand
 the benefits of having a separate bool type. Actually, I don't
 mind if there is one or not.

Feb 03 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"D" <s_nudds hotmail.com> wrote in message
news:a3lfdg$php$1 digitaldaemon.com...

 With respect to boolean types, it is essential that the language have
 predefined constants for true and false.

D has both. true is 0, false is 1. Both are of type bit.
Feb 04 2002
prev sibling parent reply Karl Bochert <kbochert ix.netcom.com> writes:
On Thu, 31 Jan 2002 11:01:07 +0200, Ruslanas Abdrachimovas
<anubis 03bar.ktu.lt> wrote:
 Oooo, no. That's not very good. "==" and "=" bugs are very common in
 C/C++ because int<->bool types are compatible in flow control 
 statements, if they weren't there were only only one possibility:
 if (bool_expr1 == bool_expr2)     OR      if (bool_expr1 = bool_expr2)

Disallow assignments in all conditionals. They are unnecessary, confusing and prone to error with any syntax.
Jan 31 2002
parent reply "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
Hi,

I'm new here, but have read the specs and followed this group with great
interrest for a few days.

"Karl Bochert" <kbochert ix.netcom.com> wrote in message
news:1103_1012528774 bose...
 Disallow  assignments in all conditionals. They are  unnecessary,

 and prone to error with any syntax.

I don't agree with you one this. Consider this C/C++ example: while ( ch=fgetc(fp), ch!=EOF && ch!='\n' ) { ... } without the assignment it might become: for (;;) { ch = fgetc(fp); if (ch==EOF || ch=='\n') { break; } ... } and the condition is moved into the loop, which I prefer to avoid if there is a simple solution to it. The for-construction above isn't valid D code according to the specs, because the increment cannot be omitted in D. Anyway, I prefer for(;;) over while(true) as the latter might lead to warnings about constant conditionals (such warnings are often very useful). For this reason I would like to see some construction that allows an "indefinite" loop without constant expressions. It might be for(;;), but a "forever" loop construction would please me just as much. Regards, Martin
Feb 01 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:a3edhg$uuk$1 digitaldaemon.com...

 The for-construction above isn't valid D code according to the specs,
 because the increment cannot be omitted in D. Anyway, I prefer for(;;)

for(;;) compiles fine.
 while(true) as the latter might lead to warnings about constant

 (such warnings are often very useful). For this reason I would like to see
 some construction that allows an "indefinite" loop without constant
 expressions. It might be for(;;), but a "forever" loop construction would
 please me just as much.

I've asked this before... but it seems that most people here don't really need it. Still it'd be pretty fine to have. I suggest while() - with no expession inside the braces - for this purpose, to avoid new keywords.
Feb 01 2002
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Pavel Minayev wrote:

 I've asked this before... but it seems that most people here don't
 really need it. Still it'd be pretty fine to have. I suggest while() -
 with no expession inside the braces - for this purpose, to avoid
 new keywords.

I don't have the exact quote, but Walter's quote was something like: "I've been programming C so long that for(i=0; i<10; i++) looks pretty much like a keyword to me." It is cool that some things are so well known that they function like keywords even though they aren't. IMHO, that's almost better than keywords...it requires less forking of the "familiarity base" -- 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))) ]
Feb 01 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3C5AD3A2.5C83B700 deming-os.org...

 I don't have the exact quote, but Walter's quote was something like:

 "I've been programming C so long that    for(i=0; i<10; i++)    looks

 much like a keyword to me."

It was related to my topic about for-each. I still think that some form of for-each would be a great advantage for the language, BTW.
Feb 01 2002
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Although I hated it at first, I have grown to (kind of) like shell
scripting's for construct:

    for <varname> in <list of items>
    do
       <run once for each item, with <varname>=<item>>
    done

I'm not sure of the right C-style syntax for this, but it would be cool to
have.

--
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))) ]
Feb 01 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3C5AE2AE.C870DB58 deming-os.org...

 Although I hated it at first, I have grown to (kind of) like shell
 scripting's for construct:

     for <varname> in <list of items>
     do
        <run once for each item, with <varname>=<item>>
     done

 I'm not sure of the right C-style syntax for this, but it would be cool to
 have.

Yeah, exactly. I suggest either: foreach (var in array) ... // was it in JavaScript? I don't remember... // problem is "in" has other meaning already -- or -- foreach (array as var) ... // PHP-like
Feb 01 2002
parent Alex Vincent <jscript pacbell.net> writes:
     foreach (var in array) ...    // was it in JavaScript? I don't
 remember...

Actually, it's: for (property in object) { /* actions. property is a string, object[property] is the actual property */
Feb 01 2002
prev sibling next sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
"Martin M. Pedersen" wrote:

 I don't agree with you one this. Consider this C/C++ example:

     while ( ch=fgetc(fp), ch!=EOF && ch!='\n' ) {
         ...
     }

 without the assignment it might become:

     for (;;) {
         ch = fgetc(fp);
         if (ch==EOF || ch=='\n') {
             break;
         }
         ...
     }

 and the condition is moved into the loop, which I prefer to avoid if there
 is a simple solution to it.

Try this. It's still not perfect, but it's a little better: ch = fgetc(fp); while(ch!=EOF && ch!='\n') { ... } I don't like the duplicated line, but it works for lack of something better. -- 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))) ]
Feb 01 2002
parent "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
Hi,

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3C5AD45E.969DDE7D deming-os.org...

ch = fgetc(fp); while(ch!=EOF && ch!='\n') { ... } I don't like the duplicated line,

You obviously does not :-) I know what you intended to write, and I don't either.
 but it works for lack of something better.

It is really a matter of taste, and personal experiences on how errors are introduced. I find the version without redundant calls to fgetc() less error prone because you only have to replace fgetc() once in case you need to do so. So, I'm sure the version I wrote first is something better for me. Regards, Martin M. Pedersen
Feb 01 2002
prev sibling parent reply "D" <s_nudds hotmail.com> writes:
land = logical and
lor = logical or
leq = logical equal

& = binary and
|  = binary or
= = binary equal

  = logical shift right


o> = Roll Right o< = Roll Left do ch = fgetc(fp) if (ch != EOF land ch != EOL) then exit ... loop
 I don't agree with you one this. Consider this C/C++ example:

     while ( ch=fgetc(fp), ch!=EOF && ch!='\n' ) {
         ...
     }

 without the assignment it might become:

     for (;;) {
         ch = fgetc(fp);
         if (ch==EOF || ch=='\n') {
             break;
         }
         ...
     }

 and the condition is moved into the loop, which I prefer to avoid if there
 is a simple solution to it.

 The for-construction above isn't valid D code according to the specs,
 because the increment cannot be omitted in D. Anyway, I prefer for(;;)

 while(true) as the latter might lead to warnings about constant

 (such warnings are often very useful). For this reason I would like to see
 some construction that allows an "indefinite" loop without constant
 expressions. It might be for(;;), but a "forever" loop construction would
 please me just as much.

 Regards,
 Martin

Feb 04 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"D" <s_nudds hotmail.com> wrote in message
news:a3lgkl$qpp$1 digitaldaemon.com...

 land = logical and
 lor = logical or
 leq = logical equal

Why not then simply "and" & "or" & "eq", and where is "not"?. And why don't you like && || ?
  = logical shift right



LOGICAL SHIFT???
 do
    ch = fgetc(fp)
    if (ch != EOF land ch !=  EOL) then exit
   ...
 loop

No Pascal, please =) while (true) { ... }
Feb 04 2002
next sibling parent reply Russell Borogove <kaleja estarcion.com> writes:
Pavel Minayev wrote:

 "D" <s_nudds hotmail.com> wrote in message
 news:a3lgkl$qpp$1 digitaldaemon.com...

  >> = logical shift right

  << = logical shift left

LOGICAL SHIFT???

Logical shift = unsigned shift = not arithmetic shift = don't shift in sign bits. Doesn't make a difference to the left shift, obviously.
Feb 04 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3C5EBDCD.5040504 estarcion.com...

 Logical shift = unsigned shift = not arithmetic shift = don't
 shift in sign bits. Doesn't make a difference to the left
 shift, obviously.

Ahh... sorry, didn't know how it's called "logical".
Feb 04 2002
prev sibling parent "D" <s_nudds hotmail.com> writes:
Pavel Minayev <evilone omen.ru> wrote in message
news:a3ll7u$svm$1 digitaldaemon.com...

 Why not then simply "and" & "or" & "eq", and where is "not"?.
 And why don't you like && || ?

&& does not in itself imply a "logical" operation rather than a numerical one. l& has an advantage over && in the regard. Having said that, "land" has both benefits and problems. As long as there is a consistant distinction made for logial vs numerical operations. In C, we have = numeric == logical & numeric && logical | numeric || logical and now the inconsistancy < logical << numeric > logical >> numeric Very unfortunate.
  = logical shift right



LOGICAL SHIFT???

Sorry Assembler vocab.
 do
    ch = fgetc(fp)
    if (ch != EOF land ch !=  EOL) then exit
   ...
 loop

No Pascal, please =) while (true) { ... }

Inferior. Simple brackets are inferior for a variety of reasons. In the above instance the opening brace is redundant and wastes a line of space. The block can start at the end of the conditional with no loss of clarity. Second, there is no type to the closing brace. Lack of block typing makes a language prone to block grouping errors. Indention is a poor replacement for proper language typing. Youi might as well omit variable typing and stipulate that variables the end with one brace are integers, two braces are floats, etc. Block typing is good. Use it.
Feb 04 2002
prev sibling next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Keith Nash" <k.j.nash usa.net> wrote in message
news:a39e2f$2gk9$1 digitaldaemon.com...

 1. The C syntax.
 C syntax is freeform: it uses ";" to separate statements, and it uses

 "{" and "}" to group statements together.  A good example of this is the
 example D program on the web page mentioned above.

 These features are unhelpful, and lead to lots of bugs.  Why?  Because,
 unlike compilers, programmers aren't good at keeping track of large

 of "{" and "}" in deeply nested structures.  So we indent our code with
 whitespace, to make it more readable.  The problem is that bugs arise when
 whitespace and braces disagree, e.g. in

 Perhaps the syntax should be more like Python than like C/C++.

We C guys have all got so used to it, I don't think it's a good idea to drop this syntax...
 Freeform (";").  It's bad coding practice to put more than one statement

 a line; it makes code difficult to read.  Style guidelines tell us not to

 it.  Why not design D so that style guidelines are unnecessary (this too

 one of D's stated aims) - so that it is difficult, if not impossible, to
 write bad code?  Use "newline", and only "newline", as a statement
 terminator.

BASIC once was like that. Now we can use colon to put several statements on one line. Sometimes, it just looks better - and clearer.
 2. Equality.
 Confusion of "=" and "==" is a common source of bugs.  Please use

 *anything*, in place of "==", even FORTRAN's ".EQ." would be better.

Then better use Pascal syntax, := for assigning and == for comparison. Or even better, leave it as is =) I like it this way
Jan 31 2002
parent reply "D" <s_nudds hotmail.com> writes:
C syntax is a fine model to follow if you wish to continually repeat the
same perpetually exposed errors.

I recommend avoiding errors.

Use ";" optionally.  EOL = ";" unless prefixed with a line continuation
token.

Pavel Minayev <evilone omen.ru> wrote in message
news:a3c1ts$2hln$1 digitaldaemon.com...
 "Keith Nash" <k.j.nash usa.net> wrote in message
 news:a39e2f$2gk9$1 digitaldaemon.com...

 We C guys have all got so used to it, I don't think it's a good
 idea to drop this syntax...

Feb 04 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"D" <s_nudds hotmail.com> wrote in message
news:a3lh1c$qtg$1 digitaldaemon.com...

 C syntax is a fine model to follow if you wish to continually repeat the
 same perpetually exposed errors.

 I recommend avoiding errors.

 Use ";" optionally.  EOL = ";" unless prefixed with a line continuation
 token.

BASIC fan, eh? =) Just indent code properly, and everything is very readable. In fact, C/C++/D code is sometimes more readable than BASIC or Pascal one, because you read much less junk.
Feb 04 2002
parent "D" <s_nudds hotmail.com> writes:
 "D" <s_nudds hotmail.com> wrote in message
 C syntax is a fine model to follow if you wish to continually repeat the
 same perpetually exposed errors.
 Use ";" optionally.  EOL = ";" unless prefixed with a line continuation
 token.


Pavel Minayev <evilone omen.ru> wrote in message news:a3lla6$svt$1 digitaldaemon.com...
 BASIC fan, eh? =)

I am, but I don't propose the method because it's the one chosen by MSBasics. It is simply a fact that line continuation is less common that <EOL>. It is also a fact that semicolons are commonly omited and their omission causes trouble. Not requiring them is therefore superior. Pavel Minayev <evilone omen.ru> wrote in message news:a3lla6$svt$1 digitaldaemon.com...
 Just indent code properly, and everything is very readable. In
 fact, C/C++/D code is sometimes more readable than BASIC or
 Pascal one, because you read much less junk.

The fact that C/C++ does not have block typing means that it is error prone and less readable than those langauges that have it. I don't recommend perpetually repeating the foolish mistakes of the past.
Feb 04 2002
prev sibling parent "Sean L. Palmer" <spalmer iname.com> writes:
Yeah, we've heard you already.

Sean

"D" <s_nudds hotmail.com> wrote in message
news:a3lh1c$qtg$1 digitaldaemon.com...
 C syntax is a fine model to follow if you wish to continually repeat the
 same perpetually exposed errors.

 I recommend avoiding errors.

 Use ";" optionally.  EOL = ";" unless prefixed with a line continuation
 token.

 Pavel Minayev <evilone omen.ru> wrote in message
 news:a3c1ts$2hln$1 digitaldaemon.com...
 "Keith Nash" <k.j.nash usa.net> wrote in message
 news:a39e2f$2gk9$1 digitaldaemon.com...

 We C guys have all got so used to it, I don't think it's a good
 idea to drop this syntax...


Feb 04 2002
prev sibling parent reply "Brian Bober" <netdemonz yahoo.com> writes:
"Keith Nash" <k.j.nash usa.net> wrote in message
news:a39e2f$2gk9$1 digitaldaemon.com...
 Greetings,

 I'm interested in the D language - here's my 2c-worth.

 The website gives a list of features to drop, at
 http://www.digitalmars.com/d/overview.html
 and it is great that the D spec is so radical in dropping unnecessary

 features.  Here are my suggestions for a couple more.

 1. The C syntax.
 C syntax is freeform: it uses ";" to separate statements, and it uses

 "{" and "}" to group statements together.  A good example of this is the
 example D program on the web page mentioned above.

This would be a problem for cross-platform code. I'm happy with the syntax. What I would like to see is an ability to do multi-line strings.
 These features are unhelpful, and lead to lots of bugs.  Why?  Because,
 unlike compilers, programmers aren't good at keeping track of large

 of "{" and "}" in deeply nested structures.  So we indent our code with
 whitespace, to make it more readable.  The problem is that bugs arise when
 whitespace and braces disagree, e.g. in

 if (blah) {
     if (blah)
     {
         blah;
         blah;
 /* This comment is not in a good place */
 }
 else
 {
     blah;
 }
 blah;
 blah;
 /* OK, this code does
  * blah blah
  */
 }

 This one's easy to spot, but you might be reading code that uses an
 unfamiliar convention for positioning braces.
 I agree that you can run the code through an indenter, or lint, but one
 stated aim of D is to remove the features of C/C++ that make it necessary

 pre-check code in this way.  Indentation will always be the most

 way to make structured code readable to humans: the example D program

 demonstrates this. So why not adopt indentation as a language feature?
 Perhaps the syntax should be more like Python than like C/C++.

 Freeform (";").  It's bad coding practice to put more than one statement

 a line; it makes code difficult to read.  Style guidelines tell us not to

 it.  Why not design D so that style guidelines are unnecessary (this too

 one of D's stated aims) - so that it is difficult, if not impossible, to
 write bad code?  Use "newline", and only "newline", as a statement
 terminator.

How about a warning or error if two statements are on the same line?
 2. Equality.
 Confusion of "=" and "==" is a common source of bugs.  Please use

 *anything*, in place of "==", even FORTRAN's ".EQ." would be better.



 Whether or not you agree with these suggestions, I suggest that the

 syntax should not be exempt from examination and improvement; not least
 because, after D has been released, we will no longer have the opportunity
 to do this.

 If you've read this far, thanks for reading.  I look forward to the day

 D replaces C/C++!

 Best wishes,

 Keith.

Feb 03 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"Brian Bober" <netdemonz yahoo.com> wrote in message
news:a3lcbu$mp5$1 digitaldaemon.com...

 What I would like to see is an
 ability to do multi-line strings.

char[] s = "first line\n" "second line\n" "third line\n" ... ;
 How about a warning or error if two statements are on the same line?

This is the same as defining EOL as end-of-statement. And I won't be able to write something like this? a++; b++; c = a + b; Never ever! =)
Feb 04 2002