Re: Operator precedence

On 2024-05-26, Christian Weisgerber <naddy@mips.inka.de> wrote:

On 2024-05-25, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>

People should be anyway aware of the operator precedences in the
various programming languages since there are obviously yet worse
definitions than the one we've been discussing here.

>
Which is why BSD has had an operator(7) man page about "C operator
precedence and order of evaluation" since 1990.

This discussion has convinced me that unary operators must not be
clumped together and put into a single precedence level.

For instance, if we have the C-like expression

  -*p/*q

it should ideally be

  -(*p/*q)

and not as it is now:

  (-*p)/(*q)

due the unary minus being clumped with dereference.

Unary minus should not be a distinct operator from binary minus.
Unary minus should denote the elision of an identity element term,
so that - X not only means the same as 0 - X, but is considered
to be the same notation, just with the additive identity element not
show. We could correctly parse it as a binary minus by putting the
element back in.

This can make a difference easily. Consider that the unsigned types
in C have a definition for unary minus. If *p is of type unsigned
int, and its value is 1, then (-*p) is UINT_MAX. *q is 4 then
we get UINT_MAX / 4.  Under the proposedd rule, we would get
something else: 1/4 producing 0, and that negating to 0.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca