On 2026-05-31 01:43, Keith Thompson wrote:Bart <bc@freeuk.com> writes:>[...][...]
C's operator precedence rules are complicated and arguably flawed.
I'd say that just the (known) flaw makes them (slightly) complicated;
so you need to remember that "flaw" (or "inconsistency") to be safe.
The rest is completely sensible. And even if one doesn't have a table
to look up the precedences they mostly can be derived (presuming one
has a feeling for the underlying logic of these things or experiences
from other related areas).
Reasonable, but I feel the need to say that that's your personal
opinion. You seem to think that C's precedence rules have one and
only one flaw, and a set of rules with that flaw corrected would
be ideal.
I don't even necessarily disagree, but others are likely to have
different opinions, and those opinions might be perfectly valid.
I don't want to make a huge deal out of this. I honestly don't have
a strong opinion myself. I usually find dealing with the rules
as they exist to be a much better use of my time and attention --
and I don't mean that as a criticism of anyone who choose to think
about alternatives.
They could have been defined differently. A simpler set of rules,>
with fewer levels, *might* have been better. I don't have any
concrete suggestions -- nor do I have any strong preferences.
I accept C's rules as they are. I would accept them if they had
been defined differently.
Nothing about the current rules particularly bothers me. There are
no objective criteria for deciding what the rules *should* be.
There are. (What I called above as "derived underlying logic".) Some
aspects have already been formulated in this and other threads here.
But maybe not obvious to recognize without background in mathematics,
logic, or CS.
>Even having multiplication bind more tightly than addition is>
fundamentally an arbitrary choice
(Now opinions are getting really strange; in the above stated sense.)
Mathematical notation almost universally has multiplication binding
more tightly than addition. It's consistent because the consistency
itself has big advantages so that you can write x + y * z (or x +
y × z) and everyone knows what you mean. Strict left-to-right
evaluation would also have been a valid choice. (I don't know the
history, but it probably goes back several centuries.)
(though one that's almost>
universally recognized, even outside the context of programming
languages).
[...]
If not, people can choose to ignore those them when writing C code,Yes, they can, and I personally tend to agree that they should.
for example like this where all () are technically superfluous:
>
crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)];
The more complex the expressions are the more structure they need.
>
IMO, the parenthesis above make precedence clear (if unknown!), but
are not contributing to readability. It would have made more sense
to separate the sub-expression within the [...] in an own object to
enhance readability and to more easily understand what's going on.
>
To emphasize; not the precedences are the problem above, but the
complexity of the expression in connexion with lack of structuring.
>>[...]When designing a new language, there are real advantages in strictly
imitating C's rules, just because so many programmers are familiar
with them.
Huh? - How that? - Are you saying here that practically only C-like
languages are in common use?
Huh? No, I didn't say that at all.
I suggest that if you're designing a somewhat C-like language,
sticking to C's precedence rules has advantages due to programmer
familiarity. Even for a language that's not particularly C-like,
but that has C-like expressions, the designer might consider
following C's rules.
Or not.
- But even if so; there's quite some
languages with differing precedence rules, not C-based, and without
such a flaw like the one being discussed. - When designing a *new*
language I'd certainly choose one of the sensible precedence rules,
and just without those obvious flaws. (And not use "C" as base, of
course.)
Certainly.
(I would have been silly for C++ or Objective-C to>
change the precedence rules, even to improve them.) But there
are also real advantages in using precedence rules that are better
(e.g., simpler) than C's.
Or - with reference to that flaw - just more consistent.
>
Consistent systems are inherently simpler, in the sense of easier to
understand and thus more straightforward to use. A precondition for
that is, as said, at least a basic understanding of such things.
Ah, but consistent with what? Internal consistency and consistency
with existing practice are not necessarily the same thing.
It depends on the nature of the language.
It could be an interesting discussion for comp.lang.misc.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
Les messages affichés proviennent d'usenet.