A
Anonymous 7843
PL/I.
PL/I.
C
C Wegrzyn
Bliss/10Anonymous said:
S
sterten
why always create a new incompatible language when you
just have some small improvements ?
you need a new compiler and your old programs will
no longer run.
K
Keith Thompson
Because sometimes a new dialect with small improvements is too close
to the original language. It can be unclear which version of the
language you're using.
I might even argue that C++'s closeness to C is a disadvantage. C and
C++ are far enough apart to be two distinct languages, but they're
still close enough that a lot of programmers think there's such a
thing as "C/C++".
B
bqbert
C said:
bliss was (is) actually cool. No C#, PL/I, Java, etc please.
J
James Dow Allen
This would be a simple one-liner in the elegant Snobol language.Sadly,
the references to Snobol that show up
with Google are mostly 6-year old messages, complaining
that Snobol has disappeared!
But this is comp.lang.c not comp.lang.snobol.
Let me try to help OP.
<diatribe>
C is a victim of its own success!
I don't think Fortran programmers ever say
"Let's make our language more like Pascal."
Ones that might ... switch to Pascal!
Similarly, while most consider some languages,
e.g. Forth or APL, to have perverse syntax,
those who go out of their way to use Forth or
APL, almost by definition, like the "perversity"!
But C's rich elegant combination of simplicity
and flexibility and the fact that it was better
suited than prior languages to a wide variety of
applications recommended itself to many expert
programmers in the 1970's and 80's and it soon
become widespread ... even among many who
couldn't appreciate its elegance.
One of the most elegant features of C is the
identity between the referencing of pointers
and array elements. Yet this seems to be
consistently confused by novices! Why? It
can't be that C is "too complicated" -- C is
based on a tiny set of elegant principles.
I think the problem is that novices can't
believe such a powerful language is *so simple*!
One example of such simplicity is the fact, as
Keith Thompson points out, that arrays are always
one-dimensional: a 2-D array is an array of
arrays.
Viewed in total isolation, the question of whether
to start array indexes at 0 or 1 may be a legitimate
open question, but in C the question answers itself
once one notices that the following expressions
(outside sizeof, etc.) must be identical in C:
*p
*(p+0)
0[p+0]
p[0+0]
p[0]
Anyone who suggests that C indexes should start at 1,
doesn't even understand this much: the idea that their
opinion on C might have merit is laughable.
Similarly, since in the 4-D array expression
a[c][d][e]
one can't know, without studying the declarations,
whether 'a' is an array of pointers to arrays
of pointers, a pointer to an array of pointers
to arrays, or one of several other possibilities,
the idea of obfuscating this further by writing
a[b,c,d,e]
suggests lack of understanding. (We're sorry if
'[' and ']' are hard to produce on German keyboards
but I'm sure there's workarounds for that.)
(Do any other languages, besides C++ and others that
model their syntax on C, have a similar elegant
array/pointer model?)
Finally, it shows grave confusion to suggest that
someone who prefers to see C syntax when they're reading
a C program should simply run 'cc -E'. We all look
at intermediate compilation results when there's a
reason, but viewing unobfuscated source shouldn't be
one of them. To give only one of the most obvious
objections, on all compilers I've tried 'cc -E' will
remove comments; did OP overlook this?
No one claims the C language is a perfect panacea, but
it has an enviable elegance. Novices should devote
themselves to grasping that elegance before offering
"improvements."
</diatribe>
James Dow Allen
S
sterten
James Dow Allen wrote:
....
I didn't suggest, that indices should start at 1,
starting at 0 is fine, but
I just suggested that e.g. int A[n]; should reserve n+1
memory-cells instead of n. Or that we have a preprocessor utility
to change int A[n] into int A[n+1] before the compiler
gets it from batch file or in a child process.
Very often you are using A[n] and want it to hold integers 1..n,
with or without 0.
I guess, this is a quite common error for C-programmers,
that they define int A[n]; and then access A[n] , e.g.
A[n]=x;
Now this may overwrite some other variable stored at [A+n]
causing strange behaviour in the program which is hard to debug.
I do consider this one of the worst problems with C.
If you think, arrays should be defined usually on A[0,..,n-1],
that's quite uncommon. Look at any math. or combinatorics
or numerics textbook or paper.
You are just _producing_ thousands of invain hours of
debugging by suggesting this A[n] - behaviour.
No matter how "beautiful" or "elegant" or
"logical" you might consider it. As I said, a programming
language has to be functional and easy to use and debug,
that's what it has been designed for, that's what it is
being used for, not elegance.
your opinion that
a[b,c,d,e] is more "obfuscated" than
a[c][d][e] seems very strange to me.
The first one is shorter and has fewer parentheses,
parentheses are always hard to follow, since you have
to keep track where they open and where they close.
It's even worse when you have nested expressions
like A[A[x][y]][z]=A[x][A[y][z]] which is nothing
more than simple associative law.
It's also completely uncommon in textbooks,papers.
yes. Give a link to the utility I'm looking for.
I don't know about cc -E
that seems to me a bit as if you enjoyed presenting problems to
novices just in order to be able to demonstrate your superior
concept of elegance.
-Guenter.
....
I didn't suggest, that indices should start at 1,
starting at 0 is fine, but
I just suggested that e.g. int A[n]; should reserve n+1
memory-cells instead of n. Or that we have a preprocessor utility
to change int A[n] into int A[n+1] before the compiler
gets it from batch file or in a child process.
Very often you are using A[n] and want it to hold integers 1..n,
with or without 0.
I guess, this is a quite common error for C-programmers,
that they define int A[n]; and then access A[n] , e.g.
A[n]=x;
Now this may overwrite some other variable stored at [A+n]
causing strange behaviour in the program which is hard to debug.
I do consider this one of the worst problems with C.
If you think, arrays should be defined usually on A[0,..,n-1],
that's quite uncommon. Look at any math. or combinatorics
or numerics textbook or paper.
You are just _producing_ thousands of invain hours of
debugging by suggesting this A[n] - behaviour.
No matter how "beautiful" or "elegant" or
"logical" you might consider it. As I said, a programming
language has to be functional and easy to use and debug,
that's what it has been designed for, that's what it is
being used for, not elegance.
your opinion that
a[b,c,d,e] is more "obfuscated" than
a[c][d][e] seems very strange to me.
The first one is shorter and has fewer parentheses,
parentheses are always hard to follow, since you have
to keep track where they open and where they close.
It's even worse when you have nested expressions
like A[A[x][y]][z]=A[x][A[y][z]] which is nothing
more than simple associative law.
It's also completely uncommon in textbooks,papers.
yes. Give a link to the utility I'm looking for.
I don't know about cc -E
that seems to me a bit as if you enjoyed presenting problems to
novices just in order to be able to demonstrate your superior
concept of elegance.
-Guenter.
K
Keith Thompson
James Dow Allen said:
Well, that's not quite true. Google "Ratfor" for details. (It's
almost topical; Brian Kernighan invented it.)
[...]
Hmm. Elegence is in the eye of the beholder, but I've never found C's
relationship between arrays and pointers particularly elegant. My
preference would be for arrays to be first-class objects, and for
array indexing to be defined as array indexing rather than being
derived from lower-level operations.
It confuses novices because it's confusing.
Of course it can't be "fixed" without breaking existing code (and
plenty of people like it the way it is).
[...]
They *must* be identical because existing code would break if they
weren't. That doesn't necessarily imply that a C-like language
couldn't be devised in which they aren't identical, and arrays behave
differently.
We agree that it's not a particularly good idea, at least in the form
the OP suggested, but we disagree about why.
[...]
I don't think that's what the OP was suggesting. He was proposing a
"preprocessor" (call it a translator or precompiler) that, for
example, changes arr[x][y] to arr[x,y]. The output of this translator
would be legible standard C.
Other that the "elegance" part, I agree.
K
Keith Thompson
As far as I know, it doesn't exist. Sorry.
S
Skarmander
It's called a C compiler with digraph support. <: and :> will beKeith said:
replaced internally with [ and ] on compilation. GCC is such a compiler.
A much better idea is to remap the keyboard or customize the editor to
produce some easy hotkey for [ and ] (easier than AltGr + some number),
since <: and :> aren't necessarily convenient either (and serves as a
nice illustration of why most people consider digraphs (and trigraphs)
next to useless).
That said, since the German QWERTZ keyboard is about as unfriendly as
possible for the standard C characters (just about anything is hidden
behind Alt or even Alt+Shift), I recommend just using a slightly
modified layout with [/{ instead of ö/Ö, and ]/} instead of ä/Ä. It
depends on your OS how easy or hard it is to define a custom layout.
You won't need German characters unless you're entering comments or
string literals, and that is easily taken care of with a hotkey for
switching layouts.
It will take a little getting used to, but it'll make for much easier
typing in the long run.
S.
B
beliavsky
James Dow Allen wrote:
Fortran 77 and 90 did borrow many features of structured programming
that already existed in Pascal and C, such as
(1) block if-else-elseif statements
(2) loops (without the need for a numbered CONTINUE in F90)
(3) user-defined types
Visual Basic, compared to the original BASIC, has undergone a similar
evolution.
Fortran 77 and 90 did borrow many features of structured programming
that already existed in Pascal and C, such as
(1) block if-else-elseif statements
(2) loops (without the need for a numbered CONTINUE in F90)
(3) user-defined types
Visual Basic, compared to the original BASIC, has undergone a similar
evolution.
T
tanmoy87544
Keith said:
Not to support rudeness ...
Or disagree with this
But this is a bad argument. I am initimately familiar with the book
.... the use of 1 based arrays was for ease of translation from
algorithms that had been coded in Fortran in previous versions of the
book, and the exact implementation invoked undefined behaviour (as you
mentioned in passing). The original Fortran coded examples were
actually useful, they were idiomatic for the language. The C examples,
when that came out, were completely unidiomatic and difficult to
follow; but a limited amount of effort had been put into it making it
useable. The Fortran 90 version, as far as I and my friends can see,
are actually almost unuseable (and I haven't looked for any more modern
versions
Yes not letting the arrays be anything other than 0 based is a weakness
of C. There are, however, very few algorithms where the structure of
the indexing set matters nontrivially, and even in those cases it is
usually the order relation that is important. In the few cases that it
does matter, sets of the form {0...b^n-1} (I am using ^ for `to the
power') are by far the most common.
I am not saying that one does not think of the first or second rather
than zeroth element: one certainly does. But that is a trivial change
during i/o or converting some field in a record. What I am saying that
when one needs to do arithmetic with the index, it is usually (but not
always) the zero based index that one wants. (Ask me! Having
programmed in various versions of Fortran now for well over twenty
years, I know how happy I was when I could use zero based arrays in
Fortran. And I also know how little it really matters in real life
when one gets used to using the `wrong' offset.)
In fact next to the indexing set {0...b^n-1}, the one I would like most
is not {1...b^n-1}, but rather {-b^n+1...b^n-1}. 1 based arrays is,
and I speak from experience, is not really a big deal.
M
Mark McIntyre
Why? Because you're incapable of recalling that the first element of
an array is at zero off set from the start? Because you're lazy?
Only when they're beginners. It must be practically the first lesson
one learns about arrays.
M
Mark McIntyre
(i'm not convinced he did, but...)
More accuirately, tehy were coded thus because the writers were
Fortran programmers who knew very little C, and seemingly lacked the
skills to reimplement their algos in C. So instead they literally
xlated the fortran, then wrote helper functions to mangle the C arrays
into fortran ones... yeuch.
Sure, there are sometimes needs for arrays not starting at one, or for
sparse arrays. C happens not to have native support for that, well
excuse me but it also doesn't have native support for fast fourier
transforms or gaussian integrals or threads, all of which would also
be useful too. Is their lack a weakness?
J
Joe Wright
Mark said:
If you can't decide whether your indexing should be rel-0 or rel-1, to
what IBM does. Use both. IBM disk formats have Tracks and Sectors. The
first track on a disk is 0. The first sector on the track is 1. Go
figure.
K
Keith Thompson
Mark McIntyre said:
Yes, I did write that, and I was very likely wrong. I briefly skimmed
the relevant section of _Numerical Recipes in C_ and came away with
the impression that the advantages of 1-based arrays are inherent to
certain algorithms rather than based on their initial implementation
in Fortran. Now that others have said that's not the case, I'll just
bow out, since I lack the expertise to say anything useful.
Arrays starting at a user-specified base index are a common feature in
a number of other languages. There's always a tradeoff between adding
features and keeping a language small and elegant, and I'm not going
to argue that C made the wrong choice. FFTs and Gaussian integrals
are (I think) more sensibly implemented as library functions; threads
can be implemented as a library too. But in any case, I don't
consider it a huge deal.
J
James Dow Allen
In C, given an array `whatever[size]' the expression
`whatever' (outside sizeof, etc.) is a pointer.
I'm sure I'm not the only who was amazed to discover
how well this works out: array arguments become, in
effect, calls by name automatically; analyzing
"multidimensional" array expressions becomes easy;
pointer and array addressing become a single thing
to understand instead of two.
C programmers are not *required* to agree that the
array/pointer relationship is *beautiful* but they
need to understand and accept it. It, unlike
trivia such as the spelling of `foo += 1', is central
to C's essence.
Given that the array/pointer relationship is essential
to C, I assume what you're suggesting is that
C could have been consistently defined so that the
expression (*p) evaluates to (p[1]). Now (*(p+6))
would be (p[7]) and so on. Did you have something
else in mind?
"Elegance" is hard to define and best grasped with
examples. The property of ordinary expressions that
*(p+6) is equivalent to p[6]
would be devastatingly less elegant if replaced with
*(p+6) is equivalent to p[7]
James D. Allen
`whatever' (outside sizeof, etc.) is a pointer.
I'm sure I'm not the only who was amazed to discover
how well this works out: array arguments become, in
effect, calls by name automatically; analyzing
"multidimensional" array expressions becomes easy;
pointer and array addressing become a single thing
to understand instead of two.
C programmers are not *required* to agree that the
array/pointer relationship is *beautiful* but they
need to understand and accept it. It, unlike
trivia such as the spelling of `foo += 1', is central
to C's essence.
Keith said:
Given that the array/pointer relationship is essential
to C, I assume what you're suggesting is that
C could have been consistently defined so that the
expression (*p) evaluates to (p[1]). Now (*(p+6))
would be (p[7]) and so on. Did you have something
else in mind?
"Elegance" is hard to define and best grasped with
examples. The property of ordinary expressions that
*(p+6) is equivalent to p[6]
would be devastatingly less elegant if replaced with
*(p+6) is equivalent to p[7]
James D. Allen
K
Keith Thompson
James Dow Allen said:
Yes, I did. What I had in mind is making arrays first-class objects,
and decoupling arrays and pointers. x[y] would be defined as the y'th
element of the array x, not as *(x+y). Array names would not decay to
pointers. Since indexing wouldn't be defined in terms of pointer
arithmetic, allowing a user-defined base (e.g., "int arr[10..20];")
wouldn't break anything further.
This is *purely* hypothetical, of course. Such a change could not be
made without breaking tons of existing code.
[...]
Absolutely. There's probably no way to provide non-zero-based arrays
in C without radical changes to the language, and I'm not advocating
any such changes. (Operator overloading might provide some
possibilities, but there's always C++ for that.)
D
Dave Thompson
Are you sure? The standard (7185) says these are just 'abbreviations'
(sugar) for the array-of-array form, and I don't recall original (J&W)
as being any different in this area.
COBOL similarly creates multidim arrays (only) as array of group
consisting of array etc., but allows abbreviated subscripting.
Fortran, PL/I, and Ada have true (distinct) multidim arrays, and the
first two have special notations for subarrays/slices. (Ada has slices
only for 1-dim arrays, the simple and easy case.) And APL of course.
- David.Thompson1 at worldnet.att.net
K
Keith Thompson
[...]Dave Thompson said:
No, I'm not sure. I haven't used Pascal in a long time, and I
probably confused its treatment of arrays with Ada's. Now that I
think about it, I believe you're right.