Re: Operator precedence

On 26.05.2024 04:06, Kaz Kylheku wrote:

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.

That's the way it goes. With proceeding discussion and studies of
yet more literature sources I came exactly to a different result,
and confidence in my (initially not that strong) view.

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.

I won't comment on the dereferencing operator in C; it's a low
level construct of a low level language that you don't find in
Algol (the language mentioned as reference) or Awk (the language
this NG is dedicated to), nor in 'bc' or spreadsheets, I suppose,
which have also been mentioned.

A note on the upthread also mentioned Ksh (which also shows this
precedence). Earlier versions of Ksh did not support '**' in
arithmetic expressions, it was added later. And (as opposed to
C's misplaced &, |, and ^ operators) they deliberately inserted
it between dyadic and monadic '-', which makes me confident that
they thought well about the appropriate place where to insert it.
(But this is of course just a detail, not a formal reasoning.)

 
Unary minus should not be a distinct operator from binary minus.

This is a statement I really find scary.

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.

But this reasoning is just artificial. Only because we can use
transformations  0-X  or -1*X  for -X  that doesn't mean that a
subtraction is the same as a negation.

We have dedicated syntax trees for monadic and dyadic operations.

 
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.

(Again low level C.)

Janis