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

"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
pretty
> 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.

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

Hi,

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C5AD45E.969DDE7D@deming-os.org...
> >
> 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,

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

"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
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.

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

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>.

"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

>     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 */

"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
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.

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
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.

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
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.
>
>
>

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>.

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.