If you could change the C or C++ or Java syntax, what would you like different?

[Seebs]

I don't know. I learnt C pretty young, and I was able to distinguish
between '=' and '==', thanks to three subtle notions:

Oh, I can distinguish between them. It's just that I'm much more likely
to get them wrong than I am more-distinct operators. Especially if I've
recently been working in a language that uses '=' for comparison. Basically,
if you present me with an otherwise mostly correct piece of code that uses
= where it should have been ==, it's quite possible for me to miss it,
especially if there are other errors which are more obvious.

I do not think C would have been a worse language had the assignment operator
been more obviously distinct, such as :=, but it wasn't, so here we are.

-s

 

[August Karlstrom]

I have no idea how far from universal "pretty much universal" is but I
can think of:

B C++ C# Objective-C D Haskell Java PHP (two equality operators
neither of which is =) Perl Python Fortran (again two, == and .eg.)
Ruby Lua Scala Erlang (two again) Algol 68 (one the two is not =)
Prolog TCL

and probably others. How many would make it not pretty much universal?

I think Bart means in the real world outside of computer programming. To
everyone who has not been exposed to programming for instance.


/August

 

[August Karlstrom]

(The gcc.info file that comes with gcc lists some 1300 options, with
other stuff inside a 27000-line file (about 500 pages when printed out..))

Holy cow, where is the emergency break?


/August

 

[Keith Thompson]

I think Bart means in the real world outside of computer programming. To
everyone who has not been exposed to programming for instance.

Agreed.

The use of "==" for equality was introduced by B, as far as I
can tell (B's ancestor BCPL apparently used "="). I suspect that
there are few, if any, uses of "==" to denote equality that are
not directly or indirectly influenced by its use in the B and
C languages.

 

[Ben Bacarisse]

You should probably widen your scope a little in order to understand
Bart's statement. This is not just about programming languages -- there
are of course quite a few borrowing this stupid idea from C. Oh, and I
don't mean to bash C ... it's just ONE really poor decision in the
language's syntax and this thread is all about hypothetical
improvements.

I just wanted to show that it's not a rare notation. I'm not saying
it's good or bad (I've given an opinion elsewhere in the thread) nor am
I saying all those languages choose their equality operators
independently. Non-programming uses seem to be a red herring because I
don't see people up in arms about * for multiplication or ! for not or
any other deviation from "real world" use. == for equality is far less
peculiar than any of these.

A computer language chooses a set of symbols that you have to learn --
normally they won't be absurd (< for equality and * for assignment would
really annoy me) but I can't get worked up about slightly infelicitous
choices such as = for assignment.

 

[Felix Palmen]

I just wanted to show that it's not a rare notation. I'm not saying
it's good or bad (I've given an opinion elsewhere in the thread) nor am
I saying all those languages choose their equality operators
independently. Non-programming uses seem to be a red herring because I
don't see people up in arms about * for multiplication or ! for not or
any other deviation from "real world" use. == for equality is far less
peculiar than any of these.

The mathematical symbols for multiplication (·) and negation (¬) are not
in US (7bit) ascii and/or not reachable on a standard PC keyboard. So, I
see your point, but I think there is still a difference…

A computer language chooses a set of symbols that you have to learn --
normally they won't be absurd (< for equality and * for assignment would
really annoy me) but I can't get worked up about slightly infelicitous
choices such as = for assignment.

I don't say it's that hard to get used to it, but still, it just wasn't
the best possible choice. Not only is "==" for equality different from
the usual symbol, but also is the standard symbol used for something
different.

Regards,
Felix

 

[Keith Thompson]

I don't say it's that hard to get used to it, but still, it just wasn't
the best possible choice. Not only is "==" for equality different from
the usual symbol, but also is the standard symbol used for something
different.

Oh? What else is "== used for?

 

[Felix Palmen]

Oh? What else is "== used for?

Maybe try to read and think again? No, I wasn't referring to "==" as a
"standard symbol"?

 

[Felix Palmen]

Yes, I agree that is what he meant, but = in mathematics is not at all
the same kind of beast as the equality operator in a programming
language. x = y + 1 is not an expression with a value -- it is a kind
of definition (or maybe a constraint). I am not at all bothered that
the operator which produces 0 or 1 from a comparison is written
differently.

It is NOT a definition. It is a claim. It reads: "x equals y + 1". Of
course, whoever writes anything like that is convinced that the claim
really is true. But whent it comes to expression evaluation, it's just
natural to check the claim and assign a boolean value to it.

Assignment is something completely different. You see assignment in
mathematics when defining a function:

f: x -> x²

So, the colon is the mathematical symbol for assignment. Following the
principle of least surprise, the colon should be used for assignment in
programming languages, too. That said, ":=" is still better (less
surprising) than just "=", which states equality in mathematics.

Regards,
Felix

 

[Keith Thompson]

Did you mean to type ":="? BCPL uses ":=" (and it's not an operator).

No, I meant "="; I was talking about equality, not assignment.
BCPL does use ":=" for assignment.

[...]

 

[Keith Thompson]

Maybe try to read and think again? No, I wasn't referring to "==" as a
"standard symbol"?

Ok, I *think* I understand what you were saying (but it took me
several re-readings).

You meant that "==" for equality is different from the usual symbol
("=") for equality, but also the standard symbol ("=") is used for
something else (assignment).

If you had written "... but also the standard symbol is used ..." I
would have found it less confusing. Perhaps a language barrier?

 

[Ben Bacarisse]

It is NOT a definition. It is a claim.

"Let x = y + 1" is often not a claim by the usual meaning of the word
(sometimes it's a claim -- let x = p/r for integer p and q might start a
proof by contradiction -- but it is not always a claim) but I really
don't want get into a fight about the definition of a very slippery
symbol.

It reads: "x equals y + 1". Of
course, whoever writes anything like that is convinced that the claim
really is true. But whent it comes to expression evaluation, it's just
natural to check the claim and assign a boolean value to it.

Except that is not done. If it were the Kronecker delta function would
be obsolete.

Assignment is something completely different. You see assignment in
mathematics when defining a function:

f: x -> x²

You also see f(x) = x².

We could go back a forth like all week long. I accept that you see
things differently. You see '=' (in maths) as a claim with a truth
value but that's not how I see it. Let's agree to differ.

So, the colon is the mathematical symbol for assignment. Following the
principle of least surprise, the colon should be used for assignment in
programming languages, too. That said, ":=" is still better (less
surprising) than just "=", which states equality in mathematics.

Yes. In fact I've agreed with this in the past. I was only commenting
on '==' which I am happy to have as distinct from the mathematical
symbol '='.

 

[August Karlstrom]

Assignment is something completely different. You see assignment in
mathematics when defining a function:

f: x -> x²

This is a definition, not an assignment, at least not in a programming
sense, since in a mathematical text you don't redefine f to be something
else later on.


/August

 

[Ben Bacarisse]

No, I meant "="; I was talking about equality, not assignment.
BCPL does use ":=" for assignment.

Somehow I though you were talking about assignment despite some very
considerable evidence to the contrary!

 

[Jon]

and what, pray tell, do you think they write, say, C++ std::string in?

Note that string literals in C++ are not std::strings.

 

[Jon]

Nonsense.

Try it and see. (I meant from the context of complete replacement of C
strings, by working at the library level cannot be done).

 

[Jon]

Bullshit. Justify this or strangle yourself immediately.

It's a too-overloaded token: dos/windows paths, line continuation,
escape... making for unnecessary contextual analysis by parsers.

 

[Jon]

If I'm reading code that uses typedef, I have to understand how typedef
works.

If I'm reading code that uses your "Alias" macro, I still have to
understand how typedef works -- *and* that "Alias" means typedef.

It doesn't help.

Think of a new programmer. Is he likely to understand that typedef means
alias in reality or likely to think that it means declaration of a new
type? Therefore, "Alias" is better.

 

[Jon]

August Karlstrom wrote:

The litmus test (C syntax):

a = sqrt(b^2 + c^2)

Anyone suggesting anything is more obvious (about the equal symbol)
than
the above is a dufus. a "equals what I tell you it equals", *I* am the
programmer. The STATEMENT (not a ponderance), says, evaluate that
expression and put the result where *I* wanted. (What all you
mathematicians are up about, I will consider).

Given the "dufus" remark, it's possible that you are not bothered about
having a debate, but assignment it very different from "making this
equal that". If the type of 'a' is int, for example, a = E; may leave
a != E in many cases.

This is, in part, an argument that quality and assignment should use
different symbols (and C complies with this) but because assignment is
asymmetric, it's a shame that the symbol isn't similarly asymmetric.
Both := and an arrow have that in their favour. It's also an argument
that assignment should not be so similar to equality that people forget
the difference, but this is almost a psychological point rather than a
programming one.

A couple of minor points: what you wrote is an expression not a
statement. It would be a statement if it had a trailing semi-colon.
Secondly, I presume that the xor b^2 is written in jest, yes? [For
anyone new to C reading this, C does not have an exponentiation
operator.]

I meant to write "C-like" syntax in the parenthetical text, given that
the debate was about the "best" tokens to do equality testing and
assignment.

 

[Juha Nieminen]

It's a too-overloaded token: dos/windows paths,

Did you know that you can use '/' to separate paths in dos/windows
as well? (Well, at least with all compilers I know.)

line continuation,

I don't think it's easy to confuse the meaning of a lone \
at the end of a line with something like "\n".

escape... making for unnecessary contextual analysis by parsers.

A "contextual analysis by parsers" is not necessary for your "paths
in dos/windows", so we are left with two, rather unambiguous, cases.