K
Kaz Kylheku
Don't forget C's "other compound statement": the comma operator.
for (int ch; ch = getchar(), ch != EOF; )
{
}
Don't forget C's "other compound statement": the comma operator.
for (int ch; ch = getchar(), ch != EOF; )
{
}
K
Kaz Kylheku
A backwards-incompatible change creates simply creates a new language or
dialect.
More like, the benefits of the introduction of a language which is not
significantly backward-compatible with anything need to be considered against
the odds of the project failing to captivate anyone's interest, or garnering
outright rejection, which are very likely outcomes no matter how good it is.
K
Keith Thompson
Edward Rutherford said:
With any other attitude, the language will die.
If you think that changing the C language to use ":=" rather than
for assignment is a good idea, that's not an unreasonable opinion,
at least at first glance. Frankly, I *wish* I could agree. But if
you want to propose such a change and have it taken seriously,
you need to address the problems it could cause (as I did in my
previous message).
So tell us, how would you address the problem of existing code that
uses "=" for assignment, and of new code using ":=" for assignment
that would no longer compile with older compilers? Similarly,
how would you address the legions of C programmers who believe
(rightly or wrongly) that using "=" for assignment and "==" for
equality is ok, and doesn't need to be fixed?
Please be specific.
K
Keith Thompson
Joe Wright said:
Huh? Please elaborate.
N
Nick Keighley
I use break if I need that control structure
for (;
{
c = getchar();
if (c == EOF) break;
process_char (c);
}
of course the structurati will drop on you like tonne of rectilinear,
fired clay building modules.
It also doesn't nest well (ok, i doesn't nest at all)
It would be sort-of half-way between a
N
Nick Keighley
Author of the famous "break Considered harmful"?
M
Malcolm McLean
You need to make the change compulsory, so the Luddites will have to
use old compilers. Otherwise you get a worse mess than the one you
were trying to solve. The new compiler gives an error, "old style
assignment operator: please run makenewstyle". So you type
makenewstyle *.c, and within seconds, all your code compiles.
There are some potential problems with diff and so on. If you've got a
decent version control system then the new code is just flagged as a
"new version", and it's no different to adding a comment, maybe a
copyright notice to comply with new corporate policy. But there will
be people for whom having two logically identical but textually
different source files will be a nuisance. Then for a while there will
be both old and new compilers in existence. You can't break old code
without some problems.
However old code with implict int will generate an unacceptable
cascade of warnings on new compilers. implicit int has just about died
out, together with old style function declarations. Changes are
possible.
Q
Quentin Carbonneaux
Well, this construct is not that new. Knuth, in "Structured Programming
with GOTO Statements" mentioned it as follows:
loop; S; while B; T; repeat;
According to this paper, it was first proposed by Ole-Johan Dahl.
S and T can be empty, so we recover while () {} and do {} while ()
loops.
Indeed, break does the trick, but some people dislike them...
with GOTO Statements" mentioned it as follows:
loop; S; while B; T; repeat;
According to this paper, it was first proposed by Ole-Johan Dahl.
S and T can be empty, so we recover while () {} and do {} while ()
loops.
I use break if I need that control structure
for (;
{
c = getchar();
if (c == EOF) break;
process_char (c);
}
of course the structurati will drop on you like tonne of rectilinear,
fired clay building modules.
It also doesn't nest well (ok, i doesn't nest at all)
Indeed, break does the trick, but some people dislike them...
N
Nick Keighley
yes I know. It was a joke. Referring Dijkstra's famous paper...
N
Nick Keighley
I consider this quasi-religious. The questions you should be asking is
"does it express the intent clearly?" "is it unnecessarily hard to
understand?". Everythign else is just unnecessary fluff
E
Edward Rutherford
Keith said:
Python has dealt with this problem very successfully, Kieth: see http://
www.python.org/dev/peps/pep-0005/ for some general approaches, but also
http://docs.python.org/release/3.0/whatsnew/3.0.html for details about
transitioning to "the first ever intentionally backwards incompatible
Python release".
One of the key planks supporting upgrades to Python 3.0 is an automated
conversion tool, 2to3 (http://docs.python.org/release/3.0/
library/2to3.html#to3-reference), which automatically upgrades 2.x source
code to valid 3.0 Python syntax.
It would be a simple matter to write a converter that read a C source
file and replaced all = assignment operators with :=
Incidentally, Python has many convenient features that could easily be
added to C, e.g. multiple comparisons behave correctly (a < b > c etc);
array and string slicing e.g. s[4:7] as a shortcut for strndup(s+4,3);
else clauses on loops; and many more. Unfortunately the current fashion
seems to be to try to preserve C in aspic.
B
BartC
Edward Rutherford said:
Python is a more superficial language. Upgrading Python sources is bit like
replacing the old window frames in a house; upgrading C is more like
replacing the mortar between the bricks.
Also it would be necessary to partition C between old C, and new C
(equivalent of versions 2.x and 3.x), and to maintain that strict
delineation. With C sources appearing everywhere on the internet, it would
be a nightmare. Effectively you would be creating a new language. It
wouldn't be worth the trouble unless you tidied up a few other things too,
and then you really would have a new language.
Actually it's not the simple, not at the character level anyway. Even using
a parser, there will be ambiguities.
As far as syntax is concerned, that's true. Even the spin-off languages
(even the latest Dart) have virtually the same 40-year-old syntax. And
strangely those languages haven't taken the opportunity to change "=" to
":=".
L
lawrence.jones
James Kuyper said:
In that case, use a for (;
loop instead.
K
Keith Thompson
Malcolm McLean said:
And you check it all into your source control system, and re-test
everything, and re-release all of it. Updating the source files
is a tiny fraction of the overhead imposed by a change like this.
The use of implicit int was never mandatory. The 1989 ANSI standard
kept the feature. C99 dropped it, but most compilers still accept
it with a warning. And if you change all your old code to declare
return types explicitly, it still compiles with old compilers.
As for old-style function declarations, they're still in the
language, even though they're clearly inferior to prototypes.
Even in the latest C201X draft they're still merely "an obsolescent
feature"; compilers are still required to support them.
In both cases, the changes to source code could be made
incrementally.
Changing "=" to ":=" as you propose is an all-or-nothing change.
If the C201X standard made such a change (it won't), there would
be a transition period of, probably, a couple of decades in which
you could either ignore the new standard altogether (the most
likely outcome for most programmers), *or* you could maintain two
versions of every single C source file. That maintenance could be
largely automated, but there would be as many inconsistent automated
solutions as there are development environments.
Oh, and try getting agreement from the C++ standard committee while
you're at it. And Objective-C (I don't know whether there's a
committee for that, but Objective-C is closely upward-compatible
with C).
If your goal is to kill an future development of the C standard,
making a wide-reaching change like this for fairly trivial benefit
is a good way to do it.
Or here's another idea. Leave "=" the way it is, and let compilers
issue an optional warning when "=" is used in a context where "=="
is probably what was meant.
K
Keith Thompson
BartC said:
There's no shortage of new languages. I have no objection at all to
ceating a new C-like language that uses ":=" for assignment and "==" for
equality. It just can't practically be a replacement for C, and it
shouldn't be called "C".
With a parser, or even just a lexer, there shouldn't be any ambiguities.
Just tokenize the source and replace every "=" token with a ":=" token.
This assumes, of course, that "=" is changed to ":=" both for
assignments and for initializers. Compound assignments presumably
wouldn't be affected; "+=" would still be "+=", not "+:=".
There might be some odd corner cases involving the preprocessor.
I
Ian Collins
To be fair, you would have to do this for any compiler upgrade. But I
do agree this is a silly idea!
K
Keith Thompson
Edward Rutherford said:
Ok, that's not a bad answer. I still don't think that it would be
at all practical to change C's assignment operator from "=" to ":=".
The overhead would be substantial, probably enough to cause many
implementers and programmers to ignore any new standard that made
such a change. (Getting C99 adopted has been difficult enough.)
C programming culture is not Python programming culture. And I'll
note that Python 2 is not dying with the introduction of Python 3.
"a < b > c" already has a meaning in C; it's equivalent to
"(a < b) > c", where "(a < b)" yields either 0 or 1. I suspect
that such constructs are used in error more often than they're used
correctly, but the committee is rightly hesitant to make changes
that can break existing code. And it's not *that* hard to write
"a < b && b > c".
I can't think of a way to define "s[4:7]" consistently in C without
radically changing the way C deals with strings and arrays. Suppose
s is a string with the value "Hello, world"; it's represented as an
array containing those 12 characters followed by a terminating '\0'.
s[4:7] should be the string "o, w", but that requires building an
array somewhere in memory with a '\0' immediately following the
'w'; you can't just treat a subset of "Hello, world" as "o, w".
And that means you have to deal with allocating, initializing,
and deallocating it.
I'm not saying that C's string and array handling are an ideal
solution, but there are uncounted millions of lines of code that
depend on it.
As for "preserv[ing] C in aspic", I refer you to
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf, the latest
(?) draft of the upcoming C201X standard. It adds threading,
alignment support, Unicode support, type-generic expressions,
static assertions, optional support for bounds-checking interfaces,
and a number of other things.
B
BartC
Keith Thompson said:
OK, that means a lexer will do instead of a parser. Although it will look
odd for static initialisers because ":=" looks more of a dynamic, runtime
assignment than a passive "=". (But more of an oddity would be having a
language that uses ":=" for assignment, but doesn't let you use "=" for
equality; you have to still use "==".)
What about commented-out code, or (rarer) code fragments inside literals?
K
Keith Thompson
BartC said:
It would have to be left alone. An automated tool should not make
assumptions about the meaning of text in comments or string literals.
Any tools that generate C code (and there are a *lot* of them)
would have to be modified as well, probably with an option to
generate old-style or new-style assignment operators.
K
Kaz Kylheku
If I could make such things compulsory, I wouldn't bother with compilers. I
would make it compulsory for, say, everyone in North America to give me a
dollar.
To hell with making some programmers use a different compiler.