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
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
> >>>>
> >>>>
> >>>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.
> >>>>
> >>>>
> >>>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
> >>>>
> >>>>
> >>>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.
> >>>>
> >>>>
> >>>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
> >>>>
> >>>>
> >>>something,
> >>>
> >>>
> >>>>*anything*, in place of "==", even FORTRAN's ".EQ." would be better.
> >>>>
> >>>>
> >>>>
> >>>personally I would prefer Pascal := as assign and == remains as equal
> >>>
> > to, if
> >
> >>>you where to change anything.
> >>>
> >>>Mike.
> >>>
> >>>
> >>>
> >>>
> >>
> >
> >
>
>

> > Math doesn't use = as assignment, neither should programming languages.
> I'm
> > 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

"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
to
> 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 =)

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

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

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.

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

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.

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,
confusing
> 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

"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(;;)
over

for(;;) compiles fine.

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

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.

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