A piece of code Bart wrote in another thread happened to relate to
something I've been working on but without me coming up with a clear
answer so I thought I'd ask you guys what you think.

The basic question is: If ^ is a postfix dereference operator then what
should be the relative precedences of the following (where E is any
subexpression)?

++E
E++
E^

(The same goes for -- but to make description easier I'll mention only ++.)

Taking a step back and considering general expression evaluation I have,
so far, been defining the apparent order. And I'd like to continue with
that. So it should be possible to combine multiple ++ operators
arbitrarily. For example,

++E + E++
++E++
V = V++

Expressions such as those would have a defined meaning. The actual
meaning is less important than it being well defined and so something a
programmer can rely on.

[[

As an aside, one thing I should point out is that while both pre-and
post-increment require an lvalue it is easy for prefix ++ to also result
in an lvalue whereas postfix ++ more naturally produces an rvalue.
Prefix ++ can be translated to

increment the value at a certain address
use that /address/

By contrast, postfix ++ more naturally translates to

load into a register the /value/ at a certain address
increment the value left at that address

After postfix ++ the address may not be so usable because its value has
already been changed and yet the code said to increment it /after/ the
operation (for some definition of 'after').

At any rate, that distinction between prefix and postfix ++ seems to be
recognised at the following link where it says "Prefix versions of the
built-in operators return references and postfix versions return values."

https://en.cppreference.com/w/cpp/language/operator_incdec

]]

Setting that aside aside ... and going back to the query, what should be
the relative precedences of the three operators? For example, how should
the following be evaluated?

++E++^
++E^++

Or should some ways of combining ^ with either or both of the ++
operators be prohibited because they make code too difficult to
understand?!!

I guess it boils down to what's most convenient and comprehensible for a
programmer but I don't know if there is a clear answer. What do you guys
think?

I've been scratching my head over this for a while so other opinions
would be most welcome!

--
James Harris

On 2022-11-07 12:55, James Harris wrote:

>   ++E + E++
>   ++E++
>   V = V++
>
> Expressions such as those would have a defined meaning. The actual
> meaning is less important than it being well defined and so something a
> programmer can rely on.

One major contribution of PL/1 was clear understanding that "every
garbage must mean something" was a bad language design principle.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 07/11/2022 12:22, Dmitry A. Kazakov wrote:
> On 2022-11-07 12:55, James Harris wrote:
>
>>    ++E + E++
>>    ++E++
>>    V = V++
>>
>> Expressions such as those would have a defined meaning. The actual
>> meaning is less important than it being well defined and so something
>> a programmer can rely on.
>
> One major contribution of PL/1 was clear understanding that "every
> garbage must mean something" was a bad language design principle.

That's all very well but what specifically would you prohibit? While
doing so be careful not to prohibit something that programmers have a
legitimate reason to want.

Perhaps another lesson from the PL/1 era was to avoid arbitrary rules.
And yet an arbitrary prohibition of something can be such a rule.

:-)

--
James Harris

On 2022-11-07 13:52, James Harris wrote:
> On 07/11/2022 12:22, Dmitry A. Kazakov wrote:
>> On 2022-11-07 12:55, James Harris wrote:
>>
>>>    ++E + E++
>>>    ++E++
>>>    V = V++
>>>
>>> Expressions such as those would have a defined meaning. The actual
>>> meaning is less important than it being well defined and so something
>>> a programmer can rely on.
>>
>> One major contribution of PL/1 was clear understanding that "every
>> garbage must mean something" was a bad language design principle.
>
> That's all very well but what specifically would you prohibit?

Your very question was about some arbitrary sequence of operators you
fail to give a meaning! Stop right here. (:-))

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 07/11/2022 11:55, James Harris wrote:
> A piece of code Bart wrote in another thread happened to relate to
> something I've been working on but without me coming up with a clear
> answer so I thought I'd ask you guys what you think.
>
> The basic question is: If ^ is a postfix dereference operator then what
> should be the relative precedences of the following (where E is any
> subexpression)?
>
>   ++E
>   E++
>   E^
>
> (The same goes for -- but to make description easier I'll mention only ++.)

For unary operators, the evaluation order is rather peculiar yet seems
to be used in quite a few languages without anyone questioning it. So if
`a b c d` are unary operators, then the following:

a b E c d

is evaluated like this:

a (b ((E c) d))

That is, first all the post-fix operators in left-to-right order, then
all the prefix ones in right-left order. It sounds bizarre when put like
that!

> Taking a step back and considering general expression evaluation I have,
> so far, been defining the apparent order. And I'd like to continue with
> that. So it should be possible to combine multiple ++ operators
> arbitrarily. For example,
>
>   ++E + E++

This is well defined, as unary operators bind more tightly than binary
ones. This is just (++E) + (++E).

However the evaluation order for '+' is not usually well-defined, so you
don't know which operand will be done first.

>   ++E++

This may not work, or not work as espected. The binding using my above
scheme means this is equivalent to ++(E++). But the second ++ requires
an lvalue as input, and yields an rvalue, which would be an invalid
input to the first ++.

>   V = V++

This one doesn't have any problems, but is probably not useful: you're
modifying V then replacing its value anyway, and with its original
value. That new V+1 value is discarded.

> Expressions such as those would have a defined meaning. The actual
> meaning is less important than it being well defined and so something a
> programmer can rely on.
>
> [[
>
> As an aside, one thing I should point out is that while both pre-and
> post-increment require an lvalue it is easy for prefix ++ to also result
> in an lvalue whereas postfix ++ more naturally produces an rvalue.
> Prefix ++ can be translated to
>
>   increment the value at a certain address
>   use that /address/
>
> By contrast, postfix ++ more naturally translates to
>
>   load into a register the /value/ at a certain address
>   increment the value left at that address
>
> After postfix ++ the address may not be so usable because its value has
> already been changed and yet the code said to increment it /after/ the
> operation (for some definition of 'after').
>
> At any rate, that distinction between prefix and postfix ++ seems to be
> recognised at the following link where it says "Prefix versions of the
> built-in operators return references and postfix versions return values."
>
>   https://en.cppreference.com/w/cpp/language/operator_incdec

I tried to get ++E++ to work using a suitable type for E, but in my
language it cannot work, as the first ++ still needs an lvalue; just an
rvalue which has a pointer type won't cut it.

However ++E++^ can work, where ^ is deref, and E is a pointer.

I think this is because in my language, for something to be a valid
lvalue, you need to be able to apply & address-of to it. The result of
E++ doesn't have an address. But (E++)^ works because & and ^ cancel
out. Or something...

> Setting that aside aside ... and going back to the query, what should be
> the relative precedences of the three operators? For example, how should
> the following be evaluated?
>
>   ++E++^
>   ++E^++
>
> Or should some ways of combining ^ with either or both of the ++
> operators be prohibited because they make code too difficult to
> understand?!!

You have the same issues in C, but that's OK because people are so
familiar with it. Also * deref is a prefix operator so you never have
two distinct postfix operators, unless you write E++ --.

But yes, parentheses are recommended when mixing certain prefix/postfix
ops. I think this one is clear enough however:

-E^

Deference E then negate the result. As is this: -E[i]; you wouldn't
assume that meant (-E)[i].

On 07/11/2022 12:55, James Harris wrote:
> A piece of code Bart wrote in another thread happened to relate to
> something I've been working on but without me coming up with a clear
> answer so I thought I'd ask you guys what you think.
>
> The basic question is: If ^ is a postfix dereference operator then what
> should be the relative precedences of the following (where E is any
> subexpression)?
>
>   ++E
>   E++
>   E^
>
> (The same goes for -- but to make description easier I'll mention only ++.)
>
> Taking a step back and considering general expression evaluation I have,
> so far, been defining the apparent order. And I'd like to continue with
> that. So it should be possible to combine multiple ++ operators
> arbitrarily. For example,
>
>   ++E + E++
>   ++E++
>   V = V++
>
> Expressions such as those would have a defined meaning. The actual
> meaning is less important than it being well defined and so something a
> programmer can rely on.

I disagree entirely - unless you include giving an error message saying
the programmer should be fired for writing gibberish as "well defined
and something you can rely on". I can appreciate not wanting such
things to be run-time undefined behaviour, but there is no reason at all
to insist that it is acceptable by the compiler.

>
> Setting that aside aside ... and going back to the query, what should be
> the relative precedences of the three operators? For example, how should
> the following be evaluated?
>
>   ++E++^
>   ++E^++
>
> Or should some ways of combining ^ with either or both of the ++
> operators be prohibited because they make code too difficult to
> understand?!!
>

Make it a syntax error. You are not trying to implement
<https://en.wikipedia.org/wiki/Brainfuck>, and are not under any
obligation to support people who want to code like that. On the other
hand, you /do/ have an obligation to try to catch mistakes, typos, and
accidental errors in code.

> I guess it boils down to what's most convenient and comprehensible for a
> programmer but I don't know if there is a clear answer. What do you guys
> think?
>
> I've been scratching my head over this for a while so other opinions
> would be most welcome!
>
>

On 07/11/2022 13:43, Dmitry A. Kazakov wrote:
> On 2022-11-07 13:52, James Harris wrote:
>> On 07/11/2022 12:22, Dmitry A. Kazakov wrote:
>>> On 2022-11-07 12:55, James Harris wrote:
>>>
>>>>    ++E + E++
>>>>    ++E++
>>>>    V = V++
>>>>
>>>> Expressions such as those would have a defined meaning. The actual
>>>> meaning is less important than it being well defined and so
>>>> something a programmer can rely on.
>>>
>>> One major contribution of PL/1 was clear understanding that "every
>>> garbage must mean something" was a bad language design principle.
>>
>> That's all very well but what specifically would you prohibit?
>
> Your very question was about some arbitrary sequence of operators you
> fail to give a meaning! Stop right here. (:-))

+ usually means numeric addition

= here presumably means an assignment (and from right to left)

++ can also be assumed to mean in-place increment. Specifically:

++E is equivalent to: (E := E + 1; E)
E++ is equivalent to: (T := E; E := E + 1; T)

(When E can be harmlessly evaluated more than once; otherwise an extra
temporary reference would need to be used.)

But I'm sure you know this already.

On 07/11/2022 15:23, Bart wrote:
> On 07/11/2022 11:55, James Harris wrote:
>> A piece of code Bart wrote in another thread happened to relate to
>> something I've been working on but without me coming up with a clear
>> answer so I thought I'd ask you guys what you think.
>>
>> The basic question is: If ^ is a postfix dereference operator then
>> what should be the relative precedences of the following (where E is
>> any subexpression)?
>>
>>    ++E
>>    E++
>>    E^
>>
>> (The same goes for -- but to make description easier I'll mention only
>> ++.)
>
> For unary operators, the evaluation order is rather peculiar yet seems
> to be used in quite a few languages without anyone questioning it.

People /do/ question it. Knowing the order for a given language, and
using the operators, does not imply liking them or not questioning them.

And note that "operator precedence" is about parsing the expression - it
is /not/ the same as "order of evaluation". A language specification
should be clear on this.

> So if
> `a b c d` are unary operators, then the following:
>
>    a b E c d
>
> is evaluated like this:
>
>       a (b ((E c) d))
>
> That is, first all the post-fix operators in left-to-right order, then
> all the prefix ones in right-left order. It sounds bizarre when put like
> that!
>
>> Taking a step back and considering general expression evaluation I
>> have, so far, been defining the apparent order. And I'd like to
>> continue with that. So it should be possible to combine multiple ++
>> operators arbitrarily. For example,
>>
>>    ++E + E++
>
>
> This is well defined, as unary operators bind more tightly than binary
> ones. This is just (++E) + (++E).
>

It is not remotely "well defined" in C, but it might be well defined in
/your/ language. The /precedence/ of the operators and the parsing of
the expression is well defined in C, but its /behaviour/ is undefined as
the order of evaluation is unspecified so the side-effects are unsequenced.

> However the evaluation order for '+' is not usually well-defined, so you
> don't know which operand will be done first.
>
>>    ++E++
>
> This may not work, or not work as espected. The binding using my above
> scheme means this is equivalent to ++(E++). But the second ++ requires
> an lvalue as input, and yields an rvalue, which would be an invalid
> input to the first ++.
>
>>    V = V++
>
> This one doesn't have any problems, but is probably not useful: you're
> modifying V then replacing its value anyway, and with its original
> value. That new V+1 value is discarded.

In C, it has /big/ problems - the side-effects on V are not sequenced,
so the expression is undefined behaviour. Other languages may differ -
you'd have to read the specifications or standards for those languages.

>>
>>    https://en.cppreference.com/w/cpp/language/operator_incdec
>
> I tried to get ++E++ to work using a suitable type for E, but in my
> language it cannot work, as the first ++ still needs an lvalue; just an
> rvalue which has a pointer type won't cut it.
>
> However ++E++^ can work, where ^ is deref, and E is a pointer.
>
> I think this is because in my language, for something to be a valid
> lvalue, you need to be able to apply & address-of to it. The result of
> E++ doesn't have an address. But (E++)^ works because & and ^ cancel
> out. Or something...
>

It is a bad sign for a language when even the language author,
implementer, and experienced user is not sure how it works. As long as
the language is only ever meant to be for a single person, you can get
away with saying "I wouldn't write that, so it doesn't matter what it
means". But if the OP has hopes that more than one person will ever see
his language, it should be specified well enough that these things are
written down.

>> Setting that aside aside ... and going back to the query, what should
>> be the relative precedences of the three operators? For example, how
>> should the following be evaluated?
>>
>>    ++E++^
>>    ++E^++
>>
>> Or should some ways of combining ^ with either or both of the ++
>> operators be prohibited because they make code too difficult to
>> understand?!!
>
> You have the same issues in C, but that's OK because people are so
> familiar with it. Also * deref is a prefix operator so you never have
> two distinct postfix operators, unless you write E++ --.
>
> But yes, parentheses are recommended when mixing certain prefix/postfix
> ops. I think this one is clear enough however:
>
>    -E^
>
> Deference E then negate the result. As is this: -E[i]; you wouldn't
> assume that meant (-E)[i].
>
>

C was fixed and unchangeable long ago (at least for such fundamental
things). A new language can be made better. If you think "parentheses
are recommend here", change it to "parentheses are /required/ here". If
you think "++E++" is confusing or questionable, make it a hard
compile-time error.

On 07/11/2022 14:58, David Brown wrote:
> On 07/11/2022 12:55, James Harris wrote:
>> A piece of code Bart wrote in another thread happened to relate to
>> something I've been working on but without me coming up with a clear
>> answer so I thought I'd ask you guys what you think.
>>
>> The basic question is: If ^ is a postfix dereference operator then
>> what should be the relative precedences of the following (where E is
>> any subexpression)?
>>
>>    ++E
>>    E++
>>    E^
>>
>> (The same goes for -- but to make description easier I'll mention only
>> ++.)
>>
>> Taking a step back and considering general expression evaluation I
>> have, so far, been defining the apparent order. And I'd like to
>> continue with that. So it should be possible to combine multiple ++
>> operators arbitrarily. For example,
>>
>>    ++E + E++
>>    ++E++
>>    V = V++
>>
>> Expressions such as those would have a defined meaning. The actual
>> meaning is less important than it being well defined and so something
>> a programmer can rely on.
>
> I disagree entirely - unless you include giving an error message saying
> the programmer should be fired for writing gibberish as "well defined
> and something you can rely on".  I can appreciate not wanting such
> things to be run-time undefined behaviour, but there is no reason at all
> to insist that it is acceptable by the compiler.

gcc accepts this C code (when E, V are both ints):

++E + E++;
V = V++;

It won't accept ++E++ because the first ++ expects an lvalue. Probably
the same will happen when you try and implement it elsewhere. So no
actual need to prohibit in the language - it just won't work.

>>
>> Setting that aside aside ... and going back to the query, what should
>> be the relative precedences of the three operators? For example, how
>> should the following be evaluated?
>>
>>    ++E++^
>>    ++E^++

> Make it a syntax error.

The equivalent in C syntax for the first is:

++*(P++);

This compiles fine when P has type int* for example. It means this:

- Increment the pointe P
- Increment the location that P now points to (using the * deref op)

So no reason to prohibit anything; it is perfectly well-defined. The
first example is equivalent to:

++((*P)++);

This won't work for the same reason as above. This is hard to prohibit
via grammar rules, but it it not necessary as it fails on type-checking.

On 07/11/2022 15:18, David Brown wrote:
> On 07/11/2022 15:23, Bart wrote:

>>>    V = V++
>>
>> This one doesn't have any problems, but is probably not useful: you're
>> modifying V then replacing its value anyway, and with its original
>> value. That new V+1 value is discarded.
>
> In C, it has /big/ problems - the side-effects on V are not sequenced,
> so the expression is undefined behaviour.  Other languages may differ -
> you'd have to read the specifications or standards for those languages.

I'd suggest that in C it would be a compiler problem. For example if it
did the assignment, and then decided to increment V.

To me that would be bizarre: I'd expect to evaluate the RHS as a single
term (V++), including any side-effects entailed, before writing the
resulting value (the old value of V) into V.

But in general you're right: I'm not keen on multiple things being
changed inside one expression. I tolerate ++ and -- (and chained
assignment) because they are so handy. But I don't allow augmented
assignments inside an expression as C does.

>> I think this is because in my language, for something to be a valid
>> lvalue, you need to be able to apply & address-of to it. The result of
>> E++ doesn't have an address. But (E++)^ works because & and ^ cancel
>> out. Or something...
>>
>
> It is a bad sign for a language when even the language author,
> implementer, and experienced user is not sure how it works.  As long as
> the language is only ever meant to be for a single person, you can get
> away with saying "I wouldn't write that, so it doesn't matter what it
> means".  But if the OP has hopes that more than one person will ever see
> his language, it should be specified well enough that these things are
> written down.

The 'or something' refers to the mechanism within my compiler which
determines what is a legal lvalue. I'd have to study 3700 lines of code
to discover exactly how it worked.

But it should be obvious (now that I've thought about it!) that a term
of the form X^, which is all that `E++^` is, should be a legal lvalue as
it can be used on either side of an assignment:

X^ := X^

(Although no doubt C will make that UB because that's what it likes to do.)

On 2022-11-07 16:06, Bart wrote:
> On 07/11/2022 13:43, Dmitry A. Kazakov wrote:
>> On 2022-11-07 13:52, James Harris wrote:
>>> On 07/11/2022 12:22, Dmitry A. Kazakov wrote:
>>>> On 2022-11-07 12:55, James Harris wrote:
>>>>
>>>>>    ++E + E++
>>>>>    ++E++
>>>>>    V = V++
>>>>>
>>>>> Expressions such as those would have a defined meaning. The actual
>>>>> meaning is less important than it being well defined and so
>>>>> something a programmer can rely on.
>>>>
>>>> One major contribution of PL/1 was clear understanding that "every
>>>> garbage must mean something" was a bad language design principle.
>>>
>>> That's all very well but what specifically would you prohibit?
>>
>> Your very question was about some arbitrary sequence of operators you
>> fail to give a meaning! Stop right here. (:-))
>
> + usually means numeric addition
>
> = here presumably means an assignment (and from right to left)

= means equality.

> ++ can also be assumed to mean in-place increment. Specifically:

++ means cheap keyboard with broken keys or coffee spilled over it... (:-))

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 07/11/2022 16:23, Bart wrote:
> On 07/11/2022 14:58, David Brown wrote:
>> On 07/11/2022 12:55, James Harris wrote:
>>> A piece of code Bart wrote in another thread happened to relate to
>>> something I've been working on but without me coming up with a clear
>>> answer so I thought I'd ask you guys what you think.
>>>
>>> The basic question is: If ^ is a postfix dereference operator then
>>> what should be the relative precedences of the following (where E is
>>> any subexpression)?
>>>
>>>    ++E
>>>    E++
>>>    E^
>>>
>>> (The same goes for -- but to make description easier I'll mention
>>> only ++.)
>>>
>>> Taking a step back and considering general expression evaluation I
>>> have, so far, been defining the apparent order. And I'd like to
>>> continue with that. So it should be possible to combine multiple ++
>>> operators arbitrarily. For example,
>>>
>>>    ++E + E++
>>>    ++E++
>>>    V = V++
>>>
>>> Expressions such as those would have a defined meaning. The actual
>>> meaning is less important than it being well defined and so something
>>> a programmer can rely on.
>>
>> I disagree entirely - unless you include giving an error message
>> saying the programmer should be fired for writing gibberish as "well
>> defined and something you can rely on".  I can appreciate not wanting
>> such things to be run-time undefined behaviour, but there is no reason
>> at all to insist that it is acceptable by the compiler.
>
> gcc accepts this C code (when E, V are both ints):
>
>
>     ++E + E++;
>     V = V++;
>

That's like saying that you can hit a screw with a hammer. Use the tool
properly, and you will see the complaints. gcc is a C compiler, not
some kind of "official" guide to the language, and everyone knows that
without flags it is far too accepting of code that has undefined
behaviour or is otherwise clearly wrong even in cases that can be
spotted easily. With even basic warning flags enabled, these are marked.

(You've had this explained to you a few hundred times over the last
decade or so. I know you get some kind of perverse pleasure out of find
any way of making C and/or gcc look bad in your own eyes, but would you
/please/ stop being such a petty child and stop writing things
deliberately intended to confuse, mislead or annoy others?)

For those that want to know the details, the most "official" C reference
site shows similar expressions as examples of undefined behaviour:

<https://en.cppreference.com/w/c/language/eval_order>

And the C standards give some related examples in section 6.5.

> It won't accept ++E++ because the first ++ expects an lvalue. Probably
> the same will happen when you try and implement it elsewhere. So no
> actual need to prohibit in the language - it just won't work.
>

That makes /no/ sense. If by "it just won't work" you mean the compiler
won't accept it, then it is prohibited by the language - or your
compiler fails to implement the language. If you mean the compiler
accepts it but it "just won't work" at run-time, then that is exactly
what we want to avoid.

>
>>>
>>> Setting that aside aside ... and going back to the query, what should
>>> be the relative precedences of the three operators? For example, how
>>> should the following be evaluated?
>>>
>>>    ++E++^
>>>    ++E^++
>
>
>> Make it a syntax error.
>
> The equivalent in C syntax for the first is:
>
>     ++*(P++);
>
> This compiles fine when P has type int* for example. It means this:
>
>   - Increment the pointe P
>   - Increment the location that P now points to (using the * deref op)
>
> So no reason to prohibit anything; it is perfectly well-defined.

There is good reason to prohibit it - you got it wrong, so despite being
well-defined by the language, it is not clear code.

The actual meaning of "++*(P++);" is :

1. Remember the original value of P - call it P_orig
2. Increment P (that is, add sizeof(*P) to it).
3. Increment the int at the location pointed to by P_orig.
4. The value of the expression is the new updated value pointed to by
P_orig.

No specific ordering of the two increments is implied here - they can be
done in either order. The compiler can assume that P and *P do not
overlap (something that could only happen using a union) - if they do,
the behaviour is undefined.

(Note that "++*(P++)" is the same as "++*P++" in C, but the extra
parentheses make it slightly less unclear.)

> The
> first example is equivalent to:
>
>     ++((*P)++);
>
> This won't work for the same reason as above. This is hard to prohibit
> via grammar rules, but it it not necessary as it fails on type-checking.
>
>

In C, prohibitions against such code come from "constraints", which are
not part of the BNF grammar rules, but come before any kind of type
checking. Whether an expression is an "rvalue", a "modifible lvalue",
"a non-modifiable lvalue", or other classification, is not part of the
type system.

Other languages may handle this sort of thing differently - I can only
say what C does here. I see no fundamental reason why it cannot be
considered part of the grammar rules, but it might need a more advanced
grammar than C has.

On 07/11/2022 16:06, Bart wrote:
> On 07/11/2022 13:43, Dmitry A. Kazakov wrote:
>> On 2022-11-07 13:52, James Harris wrote:
>>> On 07/11/2022 12:22, Dmitry A. Kazakov wrote:
>>>> On 2022-11-07 12:55, James Harris wrote:
>>>>
>>>>>    ++E + E++
>>>>>    ++E++
>>>>>    V = V++
>>>>>
>>>>> Expressions such as those would have a defined meaning. The actual
>>>>> meaning is less important than it being well defined and so
>>>>> something a programmer can rely on.
>>>>
>>>> One major contribution of PL/1 was clear understanding that "every
>>>> garbage must mean something" was a bad language design principle.
>>>
>>> That's all very well but what specifically would you prohibit?
>>
>> Your very question was about some arbitrary sequence of operators you
>> fail to give a meaning! Stop right here. (:-))
>
> + usually means numeric addition
>
> = here presumably means an assignment (and from right to left)
>
> ++ can also be assumed to mean in-place increment. Specifically:
>
>  ++E is equivalent to:  (E := E + 1;  E)
>  E++ is equivalent to:  (T := E;  E := E + 1;  T)
>
> (When E can be harmlessly evaluated more than once; otherwise an extra
> temporary reference would need to be used.)

In C, if there are side-effects from evaluating E then you will have
either undefined behaviour or at least implementation-dependent
behaviour, depending on the exact expression.

>
> But I'm sure you know this already.
>

What you have given are the interpretations for C and similar languages,
operating on arithmetic operands. Other languages may have different
meanings for the symbols. Even if the OP's language gives the same
meaning to the operators for integers, it might mean something different
for other types - including the possibility of operator overloads for
user types.

It might make sense for the language to define precedence order and
other details for the operators independent of the semantics. Or it
might make sense to have them depend on the types and the semantics -
languages differ in how they work.

On 07/11/2022 16:43, Bart wrote:
> On 07/11/2022 15:18, David Brown wrote:
>> On 07/11/2022 15:23, Bart wrote:
>
>>>>    V = V++
>>>
>>> This one doesn't have any problems, but is probably not useful:
>>> you're modifying V then replacing its value anyway, and with its
>>> original value. That new V+1 value is discarded.
>>
>> In C, it has /big/ problems - the side-effects on V are not sequenced,
>> so the expression is undefined behaviour.  Other languages may differ
>> - you'd have to read the specifications or standards for those languages.
>
> I'd suggest that in C it would be a compiler problem. For example if it
> did the assignment, and then decided to increment V.

It is not a compiler problem - it is undefined behaviour in the
language, and if someone writes that code and tries to compile it as C,
they can have no reasonable expectation of any particular behaviour.
The compiler /may/ increment V, it may not, it may reject the code with
a compiler error (if it can prove beyond doubt that the code would
actually be run - you are allowed to put code with undefined runtime
behaviour in code that is never run). Other behaviour would, I think,
be so surprising to a programmer that it would be considered a poor
implementation, even though the compiler might still be conforming.

>
> To me that would be bizarre: I'd expect to evaluate the RHS as a single
> term (V++), including any side-effects entailed, before writing the
> resulting value (the old value of V) into V.

The C language does not have a sequence point on assignment. So if you
write "x = y++;", there is no sequencing between writing to "x" or
writing the incremented value to "y". (The value of "y + 1", and the
address of "x", must be evaluated before the assignment, obviously - but
these are also not sequenced with regard to each other.) When you write
"x = y++;", that is convenient - the compiler can generate the code in
whatever order is most efficient. But if "x" and "y" refer to the same
thing, you have two unsequenced side-effects to the same objects - that
is clearly undefined behaviour.

A language could certainly have a sequence point on assignment. But C
does not do so.

>
> But in general you're right: I'm not keen on multiple things being
> changed inside one expression. I tolerate ++ and -- (and chained
> assignment) because they are so handy. But I don't allow augmented
> assignments inside an expression as C does.
>

C allows multiple things to be changed in one expression - but it does
not allow the /same/ thing to be changed multiple times without sequencing.

(I too generally prefer to change only one thing at a time in an
expression, regardless of what the language may allow.)

>
>>> I think this is because in my language, for something to be a valid
>>> lvalue, you need to be able to apply & address-of to it. The result
>>> of E++ doesn't have an address. But (E++)^ works because & and ^
>>> cancel out. Or something...
>>>
>>
>> It is a bad sign for a language when even the language author,
>> implementer, and experienced user is not sure how it works.  As long
>> as the language is only ever meant to be for a single person, you can
>> get away with saying "I wouldn't write that, so it doesn't matter what
>> it means".  But if the OP has hopes that more than one person will
>> ever see his language, it should be specified well enough that these
>> things are written down.
>
> The 'or something' refers to the mechanism within my compiler which
> determines what is a legal lvalue. I'd have to study 3700 lines of code
> to discover exactly how it worked.
>
> But it should be obvious (now that I've thought about it!) that a term
> of the form X^, which is all that `E++^` is, should be a legal lvalue as
> it can be used on either side of an assignment:
>
>     X^ := X^
>
> (Although no doubt C will make that UB because that's what it likes to do.)
>
>

"*p = *p" is fine and fully defined in C (unless you have a pointer to
volatile, when it will be implementation dependent).

"*p++ = *p++" is a different matter entirely.

On 07/11/2022 13:43, Dmitry A. Kazakov wrote:
> On 2022-11-07 13:52, James Harris wrote:
>> On 07/11/2022 12:22, Dmitry A. Kazakov wrote:
>>> On 2022-11-07 12:55, James Harris wrote:
>>>
>>>>    ++E + E++
>>>>    ++E++
>>>>    V = V++
>>>>
>>>> Expressions such as those would have a defined meaning. The actual
>>>> meaning is less important than it being well defined and so
>>>> something a programmer can rely on.
>>>
>>> One major contribution of PL/1 was clear understanding that "every
>>> garbage must mean something" was a bad language design principle.
>>
>> That's all very well but what specifically would you prohibit?
>
> Your very question was about some arbitrary sequence of operators you
> fail to give a meaning! Stop right here. (:-))

It's easy to dislike a certain sequence of operators. It's harder to
define rules for their prohibition.

A programmer has freedom to put in any sequence of operators which
comply with the syntax and semantics of the language. A language
designer, by contrast, if he wants to add a rule to prohibit certain
permutations has (a) to define what permutations are ruled out and (b)
think of the consequences of such a rule on other expressions which may
look much more legitimate.

--
James Harris

On 07/11/2022 16:43, David Brown wrote:
> On 07/11/2022 16:06, Bart wrote:

...

>> But I'm sure you know this already.
>>
>
> What you have given are the interpretations for C and similar languages,
> operating on arithmetic operands.  Other languages may have different
> meanings for the symbols.  Even if the OP's language gives the same
> meaning to the operators for integers, it might mean something different
> for other types - including the possibility of operator overloads for
> user types.

If precedences were to vary with operand types then expressions would be
vary hard for programmers to read so IMO it's important for program
readability that precedences go with the operators and that they are
independent of the types of the operands. If a programmer didn't know
what order

a + b * c

would be evaluated in until he looked up the types then even simple
programs would be very confusing.

--
James Harris

On 2022-11-07 18:26, James Harris wrote:
> On 07/11/2022 13:43, Dmitry A. Kazakov wrote:
>> On 2022-11-07 13:52, James Harris wrote:
>>> On 07/11/2022 12:22, Dmitry A. Kazakov wrote:
>>>> On 2022-11-07 12:55, James Harris wrote:
>>>>
>>>>>    ++E + E++
>>>>>    ++E++
>>>>>    V = V++
>>>>>
>>>>> Expressions such as those would have a defined meaning. The actual
>>>>> meaning is less important than it being well defined and so
>>>>> something a programmer can rely on.
>>>>
>>>> One major contribution of PL/1 was clear understanding that "every
>>>> garbage must mean something" was a bad language design principle.
>>>
>>> That's all very well but what specifically would you prohibit?
>>
>> Your very question was about some arbitrary sequence of operators you
>> fail to give a meaning! Stop right here. (:-))
>
> It's easy to dislike a certain sequence of operators. It's harder to
> define rules for their prohibition.

1. Reduce number of precedence level to logical, additive,
multiplicative, highest order.

2. Require parenthesis for mixed operations at the same level (except
for * and /)

3. No side effects of operators.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 07/11/2022 14:23, Bart wrote:
> On 07/11/2022 11:55, James Harris wrote:

...

>>    ++E++
>
> This may not work, or not work as espected. The binding using my above
> scheme means this is equivalent to ++(E++). But the second ++ requires
> an lvalue as input, and yields an rvalue, which would be an invalid
> input to the first ++.

Yes. If

++E++

is going to be permitted then for programmer sanity wouldn't it be true
to say that both ++ operators need to refer to the same lvalue? If so then

++p

should probably have higher precedence than

p++

or perhaps their precedences could be the same but they be applied in
left-to-right order.

It may be worth looking at other operators which take in AND produce
lvalues, most familiarly array indexing and field referencing, and hence
they can be incremented. Isn't it true that for both ++ operators of

++points.x[1]
points.x[1]++

that a programmer would normally want points.x[1] incremented, i.e.
field referencing and array indexing would take precedence over either
++ operator?

But now what about dereference? Should it also take precedence over the
++ operators or should it come after one or both? For instance, what
should the following mean?

++p^

Should it be

(++p)^

or

++(p^)

?

Which interpretation would programmers prefer? Frankly, I don't know
which would be best. :(

--
James Harris

On 07/11/2022 14:58, David Brown wrote:
> On 07/11/2022 12:55, James Harris wrote:
>> A piece of code Bart wrote in another thread happened to relate to
>> something I've been working on but without me coming up with a clear
>> answer so I thought I'd ask you guys what you think.
>>
>> The basic question is: If ^ is a postfix dereference operator then
>> what should be the relative precedences of the following (where E is
>> any subexpression)?
>>
>>    ++E
>>    E++
>>    E^
>>
>> (The same goes for -- but to make description easier I'll mention only
>> ++.)
>>
>> Taking a step back and considering general expression evaluation I
>> have, so far, been defining the apparent order. And I'd like to
>> continue with that. So it should be possible to combine multiple ++
>> operators arbitrarily. For example,
>>
>>    ++E + E++
>>    ++E++
>>    V = V++
>>
>> Expressions such as those would have a defined meaning. The actual
>> meaning is less important than it being well defined and so something
>> a programmer can rely on.
>
> I disagree entirely

Good. :)

> - unless you include giving an error message saying
> the programmer should be fired for writing gibberish as "well defined
> and something you can rely on".  I can appreciate not wanting such
> things to be run-time undefined behaviour, but there is no reason at all
> to insist that it is acceptable by the compiler.

As I said to Dmitry, if one wants to prohibit the above then one has to
define what exactly is being prohibited and to be careful not thereby to
prohibit something else that may be more legitimate. Further, such a
prohibition is an additional rule the programmer has to learn.

All in all, ISTM better to define such expressions. The programmer is
not forced to use them but at least if they are present in code and well
defined then their meaning will be plain.

Take the first one,

++E + E++

It could be defined fairly easily. If operands to + are defined to
appear as though they were evaluated left then right and the ++
operators are set to be of higher precedence and defined to take effect
as soon as they are evaluated than

++E + E++

would evaluate as though the operations were

++E; E++; +

If E were a variable of value 5 then the result would be

6; 6++; + ===> 12 with E ending as 7

E&OE the expression is not actually all that hard to parse if the rules
are simple.

>
>>
>> Setting that aside aside ... and going back to the query, what should
>> be the relative precedences of the three operators? For example, how
>> should the following be evaluated?
>>
>>    ++E++^
>>    ++E^++
>>
>> Or should some ways of combining ^ with either or both of the ++
>> operators be prohibited because they make code too difficult to
>> understand?!!
>>
>
> Make it a syntax error.

Why? What's so wrong with it? AISI if all three operators have the
requisite number of operands then how can it be an error in syntax?

...

> On the other
> hand, you /do/ have an obligation to try to catch mistakes, typos, and
> accidental errors in code.

Is it at least partially true that C defines a bunch of expressions as
UB because the rules were not clearly specified initially and different
compilers chose different interpretations?

With a new language I cannot see why you might be against clear
definition. I am aware that it might make optimisation harder to achieve
but that would only apply in some cases and is still, IMO, better than
simply saying "that's not defined".

IOW I welcome your disagreement but don't understand it!

--
James Harris

On 07/11/2022 18:32, James Harris wrote:
> On 07/11/2022 16:43, David Brown wrote:
>> On 07/11/2022 16:06, Bart wrote:
>
> ..
>
>>> But I'm sure you know this already.
>>>
>>
>> What you have given are the interpretations for C and similar
>> languages, operating on arithmetic operands.  Other languages may have
>> different meanings for the symbols.  Even if the OP's language gives
>> the same meaning to the operators for integers, it might mean
>> something different for other types - including the possibility of
>> operator overloads for user types.
>
> If precedences were to vary with operand types then expressions would be
> vary hard for programmers to read so IMO it's important for program
> readability that precedences go with the operators and that they are
> independent of the types of the operands. If a programmer didn't know
> what order
>
>   a + b * c
>
> would be evaluated in until he looked up the types then even simple
> programs would be very confusing.
>

Agreed - but it doesn't make it impossible to use.

And precedence is not the only feature of operators. For example, in C
and C++, the && and || operators have the additional "short-circuit"
property where the second operand is evaluated if and only if necessary,
depending on the result of the first operand. But if you overload these
operators for your own types in C++, this is not the case - they act
like normal two-input functions and evaluate (without sequencing) both
operands.

Some languages also allow you to make your own operators, perhaps also
using non-ASCII symbols. That will make some aspects of the language
more complex, but would also allow neater and clearer user code in some
cases.

(I'm not arguing for or against such things in /your/ language, merely
pointing out the possibilities.)

On 07/11/2022 20:24, James Harris wrote:
> On 07/11/2022 14:58, David Brown wrote:
>> On 07/11/2022 12:55, James Harris wrote:
>>> A piece of code Bart wrote in another thread happened to relate to
>>> something I've been working on but without me coming up with a clear
>>> answer so I thought I'd ask you guys what you think.
>>>
>>> The basic question is: If ^ is a postfix dereference operator then
>>> what should be the relative precedences of the following (where E is
>>> any subexpression)?
>>>
>>>    ++E
>>>    E++
>>>    E^
>>>
>>> (The same goes for -- but to make description easier I'll mention
>>> only ++.)
>>>
>>> Taking a step back and considering general expression evaluation I
>>> have, so far, been defining the apparent order. And I'd like to
>>> continue with that. So it should be possible to combine multiple ++
>>> operators arbitrarily. For example,
>>>
>>>    ++E + E++
>>>    ++E++
>>>    V = V++
>>>
>>> Expressions such as those would have a defined meaning. The actual
>>> meaning is less important than it being well defined and so something
>>> a programmer can rely on.
>>
>> I disagree entirely
>
> Good. :)
>
>> - unless you include giving an error message saying the programmer
>> should be fired for writing gibberish as "well defined and something
>> you can rely on".  I can appreciate not wanting such things to be
>> run-time undefined behaviour, but there is no reason at all to insist
>> that it is acceptable by the compiler.
>
> As I said to Dmitry, if one wants to prohibit the above then one has to
> define what exactly is being prohibited and to be careful not thereby to
> prohibit something else that may be more legitimate. Further, such a
> prohibition is an additional rule the programmer has to learn.

No one said this was easy! Though Dmitry had some suggestions of rules
to try.

These prohibitions aren't really additional rules for the programmer to
learn - it is primarily about disallowing things that a good programmer
is not going to write in the first place. No one should actually care
if "++E++" is allowed or not, because they should never write it.
Prohibiting it means you don't have to specify the order these operators
are applied, or whether the expression must be evaluated for
side-effects twice, or any of the rest of it. The only people that will
have to learn something extra are the sort of programmers who think it
is smart to write line noise.

>
> All in all, ISTM better to define such expressions. The programmer is
> not forced to use them but at least if they are present in code and well
> defined then their meaning will be plain.
>

No, the meaning will /not/ be plain. That's the point. Ideally you
should only allow constructs that do exactly what they appear to do,
without the reader having to study the manuals to understand some
indecipherable gibberish that is technically legal code but completely
alien to them because no sane programmer would write it.

> Take the first one,
>
>   ++E + E++
>
> It could be defined fairly easily. If operands to + are defined to
> appear as though they were evaluated left then right and the ++
> operators are set to be of higher precedence and defined to take effect
> as soon as they are evaluated than
>
>   ++E + E++
>
> would evaluate as though the operations were
>
>   ++E; E++; +
>

Then define it as "syntax error" and insist the programmer writes it
sensibly.

I cannot conceive of a reason to have a pre-increment operator in a
modern language, nor would I want post-increment to return a value (nor
any other kind of assignment). Ban side-effects in expressions -
require a statement. "x = y + 1;" is a statement, so it can affect "x".
"y++;" is a statement - a convenient abbreviation for "y = y + 1;".
"++x" no longer exists, and "x + x++;" makes no sense because it mixes
an expression and a statement.

What is the cost? The programmer might have to split things into a few
lines - but we have much bigger screens and vastly bigger disks than the
days when C was born. The programmer might need a few extra temporary
variables - these are free with modern compiler techniques.

Ask yourself why "++x;" and the like exist in languages like C. The
reason is that early compilers were weak - they were close to dumb
translators into assembly, and if you wanted efficient results using the
features of the target processor, you needed to write your code in a way
that mimicked the actual processor instructions. "INC A" was faster
than "ADD A, 1", so you write "x++" rather than "x = x + 1". This is no
longer the case in the modern world.

> If E were a variable of value 5 then the result would be
>
>   6; 6++; +  ===> 12 with E ending as 7
>
> E&OE the expression is not actually all that hard to parse if the rules
> are simple.
>
>>
>>>
>>> Setting that aside aside ... and going back to the query, what should
>>> be the relative precedences of the three operators? For example, how
>>> should the following be evaluated?
>>>
>>>    ++E++^
>>>    ++E^++
>>>
>>> Or should some ways of combining ^ with either or both of the ++
>>> operators be prohibited because they make code too difficult to
>>> understand?!!
>>>
>>
>> Make it a syntax error.
>
> Why? What's so wrong with it? AISI if all three operators have the
> requisite number of operands then how can it be an error in syntax?
>

/You/ are designing the syntax. You don't have to accept such
meaningless drivel in the code - /you/ can choose to make it a syntax
error. You can't pretend that it is a useful or intuitive code to human
eyes, so why make it legal for the compiler?

>
>> On the other hand, you /do/ have an obligation to try to catch
>> mistakes, typos, and accidental errors in code.
>
> Is it at least partially true that C defines a bunch of expressions as
> UB because the rules were not clearly specified initially and different
> compilers chose different interpretations?
>

Not really, no. Such cases are more often "implementation dependent".
Things are more often "undefined behaviour" because there is no sensible
way to define the behaviour, or no efficient way to implement defined
behaviour, or where making it UB gives more benefits (such as
optimisation opportunities or debugging/warnings/error checking/run-time
checks) than giving it a definition that would mostly be wrong. There
are a few cases of UB in C that could better as compile-time errors or
implementation-dependent behaviour.

> With a new language I cannot see why you might be against clear
> definition.

I am /for/ a clear definition - I recommend it be defined as a
compile-time error. That /is/ a clear definition, it is not undefined
behaviour.

(There are also situations where I think "undefined behaviour" is better
than defined behaviour, but that would be a different thread.)

> I am aware that it might make optimisation harder to achieve
> but that would only apply in some cases and is still, IMO, better than
> simply saying "that's not defined".
>
> IOW I welcome your disagreement but don't understand it!
>

I think it is great that you are happy to discuss this and I try my bes
to explain it.

On 07/11/2022 16:34, David Brown wrote:
> On 07/11/2022 16:23, Bart wrote:

>> gcc accepts this C code (when E, V are both ints):
>>
>>
>>      ++E + E++;
>>      V = V++;
>>
>
> That's like saying that you can hit a screw with a hammer.  Use the tool
> properly, and you will see the complaints.  gcc is a C compiler, not
> some kind of "official" guide to the language, and everyone knows that
> without flags it is far too accepting of code that has undefined
> behaviour or is otherwise clearly wrong even in cases that can be
> spotted easily.  With even basic warning flags enabled, these are marked.
>
> (You've had this explained to you a few hundred times over the last
> decade or so.  I know you get some kind of perverse pleasure out of find
> any way of making C and/or gcc look bad in your own eyes,

Well, isn't it? You recommended that a new language doesn't allow it,
but C does anyway, or at least its implementations do so.

(Unless you go out of /your/ way to ensure it doesn't pass. But you'd be
better off avoiding such code. There are a million ways of writing
nonsense code that cannot be prohibited by a compiler.)

>> It won't accept ++E++ because the first ++ expects an lvalue. Probably
>> the same will happen when you try and implement it elsewhere. So no
>> actual need to prohibit in the language - it just won't work.
>>
>
> That makes /no/ sense.  If by "it just won't work"

I mean that you will not get any C compilers to get it to work: all
report hard errors, and will not generate any code.

All the errors mention that some operand is not an lvalue. You don't
really need a special rule in grammar to prohibit certain combinations
of expressions.

For the same reasons, it won't work in other languages unless they have
very different intepretations of what ++ means.

Now compare this kind of unequivocal error report with the wishy-washing
handling of C compilers of those other two lines:

3 compilers pass them with no comment
1 compiler reports only a warning (and an invisible one to boot: Clang
shows certain messages in a light grey font, exactly the colour of my
console background!)

>> So no reason to prohibit anything; it is perfectly well-defined.
>
> There is good reason to prohibit it - you got it wrong, so despite being
> well-defined by the language, it is not clear code.
>
> The actual meaning of "++*(P++);" is :
>
>     1. Remember the original value of P - call it P_orig
>     2. Increment P (that is, add sizeof(*P) to it).
>     3. Increment the int at the location pointed to by P_orig.
>     4. The value of the expression is the new updated value pointed to
> by P_orig.

So, the meaning is that. The point is, it's well-defined and makes
sense. It may be confusing to look at, but look at ANY C source and you
will see complex expressions that are much harder to grok, like:

OP(op,3f) { F = ((F&(SF|ZF|YF|XF|PF|CF))|((F&CF)<<4)|(A&(YF|XF)))^CF;
}

(Is it even an expression? I /think/ it's function definition.)

So why single out increment operators? Because I got ++P confused with
P++ for a second? Then let's ban those two varieties of increment op too!

Note that ++*(P++) is equivalent to:

*(P += 1) += 1;

Do we ban this or not? (My language doesn't allow this, but again it's a
type issue because `+:=` doesn't return a value.

>
> No specific ordering of the two increments is implied here - they can be
> done in either order.

As I said in another post, that would be perverse.
> In C, prohibitions against such code come from "constraints", which are
> not part of the BNF grammar rules, but come before any kind of type
> checking.  Whether an expression is an "rvalue", a "modifible lvalue",
> "a non-modifiable lvalue", or other classification, is not part of the
> type system.

That's up to the implementation. In my compilers including for C,
validating lvalues is part of the type-checking.

On 07/11/2022 17:53, Dmitry A. Kazakov wrote:
> On 2022-11-07 18:26, James Harris wrote:
>> On 07/11/2022 13:43, Dmitry A. Kazakov wrote:
>>> On 2022-11-07 13:52, James Harris wrote:
>>>> On 07/11/2022 12:22, Dmitry A. Kazakov wrote:
>>>>> On 2022-11-07 12:55, James Harris wrote:
>>>>>
>>>>>>    ++E + E++
>>>>>>    ++E++
>>>>>>    V = V++
>>>>>>
>>>>>> Expressions such as those would have a defined meaning. The actual
>>>>>> meaning is less important than it being well defined and so
>>>>>> something a programmer can rely on.
>>>>>
>>>>> One major contribution of PL/1 was clear understanding that "every
>>>>> garbage must mean something" was a bad language design principle.
>>>>
>>>> That's all very well but what specifically would you prohibit?
>>>
>>> Your very question was about some arbitrary sequence of operators you
>>> fail to give a meaning! Stop right here. (:-))
>>
>> It's easy to dislike a certain sequence of operators. It's harder to
>> define rules for their prohibition.
>
> 1. Reduce number of precedence level to logical, additive,
> multiplicative, highest order.
>
> 2. Require parenthesis for mixed operations at the same level (except
> for * and /)
>
> 3. No side effects of operators.

Good suggestions, especially ruling out operators with side effects. You
wouldn't believe how much trouble they've been giving me. (It would be
alright if one was willing to make a language out of all kinds of odd
features but not if one wants a language to be cohesive.)

I like the simplicity of the language which would result from your
suggestions but can't help but think they would make programming in it
less comfortable, like the simplicity of a hair shirt. ;)

--
James Harris

On 2022-11-08 09:04, James Harris wrote:

> I like the simplicity of the language which would result from your
> suggestions but can't help but think they would make programming in it
> less comfortable, like the simplicity of a hair shirt. ;)

If you think programmers are dying to write stuff like *p++=*q++; you
are wrong. Actually that train left the station. Today C++ fun is
templates. It is monstrous instantiations over instantiations barely
resembling program code. Modern times is a glorious combination of
Python performance with K&R C readability! (:-))

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 08/11/2022 01:15, Bart wrote:
> On 07/11/2022 16:34, David Brown wrote:
>> On 07/11/2022 16:23, Bart wrote:
>
>>> gcc accepts this C code (when E, V are both ints):
>>>
>>>
>>>      ++E + E++;
>>>      V = V++;
>>>
>>
>> That's like saying that you can hit a screw with a hammer.  Use the
>> tool properly, and you will see the complaints.  gcc is a C compiler,
>> not some kind of "official" guide to the language, and everyone knows
>> that without flags it is far too accepting of code that has undefined
>> behaviour or is otherwise clearly wrong even in cases that can be
>> spotted easily.  With even basic warning flags enabled, these are marked.
>>
>> (You've had this explained to you a few hundred times over the last
>> decade or so.  I know you get some kind of perverse pleasure out of
>> find any way of making C and/or gcc look bad in your own eyes,
>
> Well, isn't it? You recommended that a new language doesn't allow it,
> but C does anyway, or at least its implementations do so.

C is a language from 5 decades ago, and has its flaws. Learn from them
and avoid repeating them in new languages. gcc is a tool for compiling
programs written in C that is essential for an enormous mass of existing
code. A major feature is that it must remain compatible with existing
usage and existing code, when used in the same way as before - this
greatly restricts the features it can provide by default. So you need
to use compiler flags to change default behaviour.

How can this be difficult for you to understand? I don't believe it is.
You are a smart guy - yet you insist on playing the fool, again and
again. For years, you have posted to comp.lang.c with your hatred and
misunderstandings about C and its tools, sometimes deliberately trying
to confuse and mislead others who are newer to the language. Please
don't do it here too.

>
> (Unless you go out of /your/ way to ensure it doesn't pass. But you'd be
> better off avoiding such code. There are a million ways of writing
> nonsense code that cannot be prohibited by a compiler.)
>

Yes, because "gcc -Wall" is /so/ hard to write. I mean, it takes hours
extra work, far out of your way. Write yourself a batch file with gcc
flags - you could have done it 20 years ago and saved yourself and
everyone else enormous effort.

A major point of a good programming language - aided by good tools - is
to reduce the amount of bad code that is accepted. Of course people
could write perfect code without the help from tools, but people are
usually imperfect and write bad code sometimes, knowingly or
unknowingly. As you say, a compiler can't prohibit all nonsense code,
but languages and tools can be designed to do their best.

>>> It won't accept ++E++ because the first ++ expects an lvalue.
>>> Probably the same will happen when you try and implement it
>>> elsewhere. So no actual need to prohibit in the language - it just
>>> won't work.
>>>
>>
>> That makes /no/ sense.  If by "it just won't work"
>
> I mean that you will not get any C compilers to get it to work: all
> report hard errors, and will not generate any code.
>

So it is prohibited by the language.

> All the errors mention that some operand is not an lvalue. You don't
> really need a special rule in grammar to prohibit certain combinations
> of expressions.

No, indeed you don't - because it is prohibited by the language.

>
> For the same reasons, it won't work in other languages unless they have
> very different intepretations of what ++ means.
>
> Now compare this kind of unequivocal error report with the wishy-washing
> handling of C compilers of those other two lines:
>

No, let's not. We are not talking about C - we are talking about how
the OP might handle such code in /his/ language. And if you want to
talk about C, grow up and use proper tools in a proper manner.

>
>>> So no reason to prohibit anything; it is perfectly well-defined.
>>
>> There is good reason to prohibit it - you got it wrong, so despite
>> being well-defined by the language, it is not clear code.
>>
>> The actual meaning of "++*(P++);" is :
>>
>>      1. Remember the original value of P - call it P_orig
>>      2. Increment P (that is, add sizeof(*P) to it).
>>      3. Increment the int at the location pointed to by P_orig.
>>      4. The value of the expression is the new updated value pointed
>> to by P_orig.
>
> So, the meaning is that. The point is, it's well-defined and makes
> sense.

It makes sense to the language - it does not make sense to humans (the
fact that /you/ got it wrong proves this, if there were any doubt).
Therefore it is not good programming. Therefore, if it is practical for
a language and/or tool to disallow it without too much other harm to the
language, it should disallow it.

> It may be confusing to look at, but look at ANY C source and you
> will see complex expressions that are much harder to grok, like:
>
> OP(op,3f) { F = ((F&(SF|ZF|YF|XF|PF|CF))|((F&CF)<<4)|(A&(YF|XF)))^CF;
>          }
>
> (Is it even an expression? I /think/ it's function definition.)

Are you arguing that because some people write C code that is even
harder to understand, the OP should allow these nonsense expressions in
his language? That "logic" is like saying that because there are bank
robbers, people should be allowed to drunk-drive.

>
> So why single out increment operators? Because I got ++P confused with
> P++ for a second? Then let's ban those two varieties of increment op too!
>

No one is singling out these operators - it's just the example the OP gave.

And yes, ban ++P - it is a pointless operator now. (See my other post
discussing that.)

> Note that ++*(P++) is equivalent to:
>
>   *(P += 1) += 1;

No, it is not. Again, your mistakes show why it is a really bad idea to
allow these kinds of expression.

>
> Do we ban this or not? (My language doesn't allow this, but again it's a
> type issue because `+:=` doesn't return a value.
>

Good. Assignment should be a statement, not an expression, and should
not return a value.

>
>>
>> No specific ordering of the two increments is implied here - they can
>> be done in either order.
>
> As I said in another post, that would be perverse.
>> In C, prohibitions against such code come from "constraints", which
>> are not part of the BNF grammar rules, but come before any kind of
>> type checking.  Whether an expression is an "rvalue", a "modifible
>> lvalue", "a non-modifiable lvalue", or other classification, is not
>> part of the type system.
>
> That's up to the implementation. In my compilers including for C,
> validating lvalues is part of the type-checking.
>

You can mix up phases of translation as much as you want, and you can
happily check lvalue/rvalue constraints in the same part of the code as
you do type checking. But that does not make lvalue/rvalue
classification anything to do with types in C.