const integers

[Flash Gordon]

Richard Heathfield wrote:

Failing to attribute constitutes incorrect attribution.

This is another complaint. I agree with everything Richard Heathfield
and Keith Thompson have said on this topic.

 

[jaysome]

[snip]

If I were designing a new language from scratch, I'd probably use ":="
for assignment and "=" for equality.

Which is what Ada uses. Having used both Ada and C extensively, I
agree with you. Making such a change would break some code, but not in
a universal way. Some like to do this:

while ((EOF != (ch = getc(f))) && ('\n' != ch)) {

while others like to do this:

ch = getc(f);
while ( (ch != EOF) && (ch != '\n') )
{

One would break, one wouldn't.

 

[Ian Collins]

Gordon Burditt quoted Keith Thompson as saying:



but failed to attribute it.

Gordon Burditt replied:




Lack of attribution /is/ misattribution, so please stop doing it.




Failing to attribute constitutes incorrect attribution.




Consider this a complaint at your failure to get attributions right.

This is yet another complaint. Attributions are important, not just here
but elsewhere on Usenet.

I also agree with everything Richard Heathfield and Keith Thompson have
said on this topic.

 

[Keith Thompson]

[snip]

If I were designing a new language from scratch, I'd probably use ":="
for assignment and "=" for equality.

Which is what Ada uses. Having used both Ada and C extensively, I
agree with you. Making such a change would break some code, but not in
a universal way. Some like to do this:

while ((EOF != (ch = getc(f))) && ('\n' != ch)) {

while others like to do this:

ch = getc(f);
while ( (ch != EOF) && (ch != '\n') )
{

One would break, one wouldn't.

I think you missed my point. I was talking using ":=" rather than "="
for assignment, and "=" rather than "==" for equality. Based on your
examples, I think you're talking not treating assignments as
expressions, but as a kind of statement (something Ada also does).
That change, assuming we keep the "=" symbol for assignment, would
break your first example but not your second.

For the record, I would strongly oppose making either change to C.
Making assignments illegal in expressions would break a great deal of
C source code that's currently perfectly valid; changing such code, in
addition to being a waste of time, would undoubtedly introduce bugs.
Making "=" denote equality rather than comparison would *quietly*
break almost every C program in existence; it would continue to
compile, but would stop working.

As I said, these are things I'd consider doing if I were designing a
new language from scratch. (Don't worry, folks, I don't have any
plans to do so.)

<OT>
Well, that's not *quite* true. I did invent the "99" language
for www.99-bottles-of-beer.net.
</OT>

 

[Mark McIntyre]

Consider something like this:

char *s = "hello";
some_func(s);

If some_func() modified the string pointed to by s, the code is
unsafe. If s were a pointer to const char, this would be caught at
the point of the call.

Mhm, indeed. Mind you thats a fairly unusual example, since strings
are the only data type with a subclass which is secretly constant. Its
harder to get that sort of error with doubles or ints.

I've added an "OT:" tag to the subject header. If this discussion
continues, we might want to take it to comp.lang.misc.

Indeed, you're right, lets drop it.

Here's a trivial example: a swap routine:

void swap_int(int *x, int *y)
{
int tmp = *x;
*x = *y;
*y = tmp;
}

tmp is never modified after its initialization, but how many C
programmers would bother to declare it const?

Very few I expect. But then its not *really* a constant - consider:

swap(p, q);
swap(r,s);

I guess the point is that its dangerous to generalise

To return to something vaguely approaching topicality, I suppose I'm
advocating more use of "const" for objects that don't change after
they're initialized.

Can't argue with that.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

You are getting it /wrong/ consistently.

For the record, I agree with Richard.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Michael Wojcik]

<OT>

One of my radical language design ideas is to make all declared
objects const by default. If you want to be able to modify an
object's value, you'd need to explicitly qualify it with, say, "var".

...

Of course, such a radical change would be inappropriate for C, and I'd
strongly oppose it if there were any chance of it being taken
seriously. But designers of new languages might want to consider it.

</OT>

Sheer liberalism, I call it. In Erlang, for example, all "variables"
are const; their values can never change once they've been assigned.
Now that's a bit of rigor.

Of course, Erlang is designed for writing programs that are largely
correct and free of bugs, which makes it unsuitable for general
software development.

--
Michael Wojcik (e-mail address removed)

Most people believe that anything that is true is true for a reason.
These theorems show that some things are true for no reason at all,
i.e., accidentally, or at random. -- G J Chaitin

 

[Keith Thompson]

On Sun, 23 Jul 2006 23:28:50 GMT, in comp.lang.c , Keith Thompson


Indeed, you're right, lets drop it.

I'm dropping the discussion of the hypothetical language change, but
....

Very few I expect. But then its not *really* a constant - consider:

swap(p, q);
swap(r,s);

It's certainly not constant (in the sense used by the C standard), but
it certainly is, or could be, const, i.e., read-only. The object
"tmp" doesn't have its value modified after its initialization. The
two calls to swap() create two distinct objects, both called "tmp".

You could change
int tmp = *x;
to
const int tmp = *x;
and the compiler wouldn't complain.

 

[Jack Klein]

[yet another reply without attribution or a proper signature line]

Your persistent rudeness is getting very tiresome.

 

[Jack Klein]

[snip]

The attribution cabal has raised the bar on correct attibutions
high enough that I have no chance of getting it right consistently:
just not deleting the attributions and letting my newsreader do its
thing with the attributions is NOT sufficient, contrary to prior
claims of some of them

[snip]

Perhaps you need a better newsreader? And how does your attribution
phobia excuse failure to use a proper signature delimiter?

 

[Richard Bos]

Sheer liberalism, I call it. In Erlang, for example, all "variables"
are const; their values can never change once they've been assigned.
Now that's a bit of rigor.

Must make it really... interesting... to write a useful summation loop.

Richard

 

[Richard Heathfield]

Richard Bos said:

Must make it really... interesting... to write a useful summation loop.

Hardly. Here it is in C:

unsigned long sum(unsigned long *p, size_t n)
{
return (n > 1) ? (sum(p, n / 2) +
sum(p + n / 2, n / 2) +
((n % 2) ? p[n - 1] : 0))
: p[0];
}

 

[Chris Dollin]

Must make it really... interesting... to write a useful summation loop.

What are these "loops" of which you speak?

[OK, I admit it, I haven't looked to see if Erlang has loops. But, you
know, it might not: loops are just a combination of syntactic sugar
and an optimisation feature of imperative languages.]

 

[Richard Bos]

Must make it really... interesting... to write a useful summation loop.

What are these "loops" of which you speak?

[OK, I admit it, I haven't looked to see if Erlang has loops. But, you
know, it might not: loops are just a combination of syntactic sugar
and an optimisation feature of imperative languages.]

Well, Erlang might be a strictly functional language, in which case it
does indeed not have loops. But then, I stand by my comment; I find
writing code that is both legible and efficient in strictly functional
languages definitely interesting, in the Chinese-proverb sense.

Richard

 

[Chris Dollin]

Must make it really... interesting... to write a useful summation loop.

What are these "loops" of which you speak?

[OK, I admit it, I haven't looked to see if Erlang has loops. But, you
know, it might not: loops are just a combination of syntactic sugar
and an optimisation feature of imperative languages.]

Well, Erlang might be a strictly functional language, in which case it
does indeed not have loops. But then, I stand by my comment; I find
writing code that is both legible and efficient in strictly functional
languages definitely interesting, in the Chinese-proverb sense.

If I remember correctly, Erlang isn't strictly functional - it has
state, although you can write a lot of stuff without it. (The same
is true of ML.)

Functional languages will be efficient competitors with imperative
languages (of which OO languages are a subset) in the near future.

Whether this is the same near future that holds commercial fusion
power and the paperless office I wouldn't like to say.

 

[Tak-Shing Chan]

Must make it really... interesting... to write a useful summation loop.

What are these "loops" of which you speak?

[OK, I admit it, I haven't looked to see if Erlang has loops. But, you
know, it might not: loops are just a combination of syntactic sugar
and an optimisation feature of imperative languages.]

One can certainly write such a summation ``loop'' by
recursion:

#include <stdio.h>

int f(const int *x) {
return (*x != EOF) ? *x + f(x + 1) : 0;
}

int main(void) {
const int a[] = {1, 2, 3, EOF}, b[] = {4, 5, 6, EOF};
printf("The sum of a is %d.\n", f(a));
printf("The sum of b is %d.\n", f(b));
return 0;
}

Note that all objects above are not modifiable.

Tak-Shing

 

[Michael Wojcik]

Must make it really... interesting... to write a useful summation loop.

Interesting is in the eye of the beholder, I suppose, but:

sum([]) -> 0;
sum([First | Rest]) -> First + sum(Rest).

Erlang's a functional language, so looping is typically implemented
with recursion. If you prefer the tail-recursive version:

sum_r([], N) -> N;
sum_r([First | Rest], N) -> sum_r(Rest, First + N).
sum(List) -> sum_r(List, 0).

NB. I actually know very little about Erlang - I've just read some
docs and played around with it a bit. Those two seem to work, though.

--
Michael Wojcik (e-mail address removed)

Couldn't "scotomisation" be defined as the removal from one's kernel
of any code belonging to the Santa Cruz Operation, Caldera, or their
heirs and assigns? -- "skotizo"

 

[Keith Thompson]

Functional languages will be efficient competitors with imperative
languages (of which OO languages are a subset) in the near future.

Whether this is the same near future that holds commercial fusion
power and the paperless office I wouldn't like to say.

Good We've instituted a paperless office policy.

Bad We're starting wih the restrooms.

 

[Mark McIntyre]

Following up my own post, I was most interested to notice an article
on The Register dated today, dealing with this very topic and indeed
discussing and advocating some of the same solutions. Methinks theres
a secret journo amongst us...

http://www.regdeveloper.co.uk/2006/07/26/constants_are_not/

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Frederick Gotham]

Mark McIntyre posted:

Following up my own post, I was most interested to notice an article
on The Register dated today, dealing with this very topic and indeed
discussing and advocating some of the same solutions. Methinks theres
a secret journo amongst us...

http://www.regdeveloper.co.uk/2006/07/26/constants_are_not/

Not worth the paper it's printed on.

It's possible to invoke Undefined Behaviour in C++ -- one should accept that
before writing such an article.